Talk:Instruction set

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Hardware (Rated Start-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by Computer hardware task force (marked as Top-importance).

Instruction Encoding[edit]

Suggested addition concerning the encoding of instructions: Instructions are encoded in a prefix code, enabling the processor to decode a sequence of concatenated instructions in memory without any ambiguities. — Preceding unsigned comment added by (talk) 13:30, 16 November 2011 (UTC)

Is that, in fact, true of all instruction sets? All the processor needs to know in order to decode a sequence of instructions in memory is the lengths of the instructions; for most if not all RISC processors, all instructions have the same length, and even for CISC processors it's possible to determine the instruction length from the opcode and, for instruction sets with multiple addressing modes, the addressing modes. Guy Harris (talk) 22:01, 16 November 2011 (UTC)
Historically there have been a lot of different encoding schemes, including opcodes that modify the format and interpretation of succeeding instructions. I'd recommend that any new section on instruction decoding present a few examples without implying that the encoding in the examples is universal. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:06, 16 November 2011 (UTC)
Nothing was said regarding the length of the instructions, whether or not they all need to be of the same length, whether they consist of a single opcode or a group of opcode (working as a single group)... The simple truth is that the CPU needs to be able to determine the 'next' instruction in memory without ambiguity, and therefore the encoding is a prefix code by definition: there is no valid code word in the system that is a prefix (start) of any other valid code word in the set (the "prefix property"). — Preceding unsigned comment added by (talk) 21:10, 20 November 2011 (UTC)
The processor needs to be able to decode each instruction in memory without ambiguity, and would need to do so even if it were a (generally non-useful) processor that fetches and executes one instruction from memory and halts; "concatenated" is, ultimately, irrelevant here, as, even in the hypothetical halts-after-one-instruction processor, which doesn't support concatenated instructions, instructions need to be encoded in such a fashion that a given sequence of bytes that encodes to a valid instruction only encodes to one valid instruction. A consequence of that is that the processor knows which bits in the instruction stream correspond to the instruction and, therefore, if it's a processor that keeps fetching and executing instructions after executing the first instruction, knows where the next instruction starts (right after the previous instruction, following any relevant padding).
So, yes, it's a prefix code in that a given sequence of bits cannot both be a complete instruction and part of a longer complete instruction, because, otherwise, once the instruction fetch-and-decode unit has fetched all the bits in that sequence, it would not know whether to stop and execute the shorter instruction or keep fetching the remaining bits of the longer instruction. "You have to be able to find the next instruction" isn't the reason for that; "you have to be able to figure out which bits correspond to this instruction" is the reason for that, and being able to find the next instruction is a consequence of that. Guy Harris (talk) 00:36, 21 November 2011 (UTC)
For a less-artificial example, consider a 32-bit word-oriented general-register load-store machine with 32 general registers, in which all instructions fit in one word. It's trivial to find the next instruction - if the current instruction is at the address N, the next instruction is at the address N+1 - but if, say, load/store instructions are encoded with an 8-bit opcode, a 5-bit operand register, two 5-bit index registers, and a 9-bit displacement, and arithmetic instructions are encoded with a 16-bit opcode, two 5-bit source operand registers, and one 5-bit destination operand register, and the opcode for "load 32-bit word" is 0x9f and the opcode for "add integer" is 0x9f01, you can't tell a "load 32-bit word" instruction that loads register 0 from an "add integer" instruction. Whether that instruction encoding is a prefix code or not depends, I guess, on what you'd call a code word.... Guy Harris (talk) 02:05, 21 November 2011 (UTC)


I have included a simple definition for mortals.

Link to this page from this page for "instruction"[edit]

in the first sentence there's a link to instruction (computer science) that redirects to the article itself (an endless recursion if you will) - what's that supposed to be? I didn't wanna take that off before asking here. thnx! —Preceding unsigned comment added by (talk) 17:58, 8 March 2011 (UTC)

It's left over from when instruction set and instruction (computer science) were separate pages; they were merged on 30 January 2011, and instruction (computer science) was made to redirect to instruction set. The link should be removed (but not the word "instruction" itself). Guy Harris (talk) 18:08, 8 March 2011 (UTC)
Fixed. --Wtshymanski (talk) 18:49, 8 March 2011 (UTC)

Machine language, ISA[edit]

The lengthy assembly language article discusses basic instruction set elements that seem better placed here. This article, in contrast, goes into relatively great detail about ISA and engineering issues not of interest to the general reader. Basically, instruction set strikes me as a fundamental encyclopedic entry, one that should be accessible to the non-engineer. I suggest moving the deeper wires-and-pliers content into an ISA article, and into others (microprogramming, RISC,...). I think we should make this a more general/overview discussion of how CPUs work -- registers, interrupts, stacks, addressing modes, etc., preferably with some nice pictures. Much of what remains here should consist of overview statements with links to specific hardware topics. Comments? Trevor Hanson 21:13, 27 October 2006 (UTC)

I totally agree with Trevor Hanson's suggestion. Hope this new 'ISA' entry for Wikipedia will be completed eventually. Before the end of times would be nice... :-) —The preceding unsigned comment was added by (talkcontribs) 19:57, 27 June 2007. [moved from end to this heading]
It will just take somebody deciding to roll up their sleeves and do it. Volunteers? Trevor Hanson 20:23, 27 June 2007 (UTC)
Additionally, are the words 'conjunction' and 'disjunction' really necessary here? Surely 'and' and 'or' would be more accessible and no less precise. (also xor is missing) (talk) 14:53, 7 November 2010 (UTC)
Then why don't you change them? Be bold!Adrian Willenbücher (talk) 17:35, 7 November 2010 (UTC)


0-operand ("zero address machines") -- these are also called stack machines, and all operations take place using the top one or two positions on the stack. Adding two numbers here can be done with four instructions: push a, push b, add, pop c;

Why is it called 0-operand even though a, b and c are operands? --Abdull 12:19, 2 December 2006 (UTC)

Uh, because the "add" instruction has no explicit operands; it works with stack values. Operands are retrieved and stored using separate push/pop operations. (Obviously those operations have a single operand.) Trevor Hanson 01:49, 28 December 2006 (UTC)
Abdul certainly has a point, "0-operand" is a somewhat silly (misleading) name, as there actually are two (implicit) operands for the addition above. Also, the result is physically stored back in one of them, much like it would in a conventional 2-address machine (but without having to specify a register or an address). Stack machine is much better term (or zero address for that matter). /HenkeB 05:00, 14 August 2007 (UTC)
The term is in wide use. Moreover, there is no requirement that the operands get "physically stored" back in some storage space, like a 2-address machine; the stack could be entirely in cache or pipeline. (Perhaps more important for me is the meaning of the term "operand" – which usually suggests a placeholder, e.g. part of a lambda-expression. Stack operations have no such flexibility – you don't say ADD X, but just ADD. One can therefore reasonably say there is no "operand" in that sense, i.e. there is no formal parameter available for substitution.) Anyway, regardless of whether the term is deemed confusing or silly, it seems to be part of processor taxonomy. I don't think we want to reinvent terminology to suit our preferences. Trevor Hanson 07:26, 14 August 2007 (UTC)
Of course it must be stored back in the stack - otherwise pop c wouldn't work in the example above - whether this stack is in main memory, cache, pipeline, and/or some other latching structure is irrelevant in this context.
With the risk of sounding even more patronizing: An operand is fairly well defined as primarily a datum used in an arithmetical calculation (such as in 2+2 or sin x) while a parameter doesn't necessarily have to be an operand. An address, furthermore, is a place where to find the parameter. It is therefore better to say zero-address than 0-parameter machine, as no operand address has to be specified in the machine code for a stack machine; the operand itself must be specified however - via push instructions.
This is not so much about preferences, more about semantics. We have to watch our language usage and conventions (even established) in order to prevent terminology from becoming too self contradictory, it's more or less a duty as I see it. /HenkeB 09:14, 14 August 2007 (UTC)

Alas, while I find myself agreeing with HenkeB, I must point out that people talking about computer architecture often use "operand" very differently than people talking about math. An assembler creates the bit pattern for a full instruction by combining (typically) 2 groups of bits. One group (the "opcode") chooses the kind of operation the instruction does, and also decides the length and format of the other group of bits. The other group of bits in a full instruction are the "operands". Each operand is either a literal value, the "address" of a particular register, or a memory address. (The actual *values* in that register or at that memory location are not "operands" in this sense). The "zero-operand" machines have instructions that are all-opcode, no-operand. The TTA machines are the opposite extreme -- no bits of opcode, all the bits are in the operand.

I suspect the example "push a, push b, add, pop c;" may be unnecessarily confusing. It certainly appears to have 1 operand. I've seen a "zero-operand" machine that truly has no operands -- [The Minimal CISC] -- but this is just a toy.

Perhaps a less-confusing example would be based on a serious "zero-operand" machine: "constant a, load, constant b, load, add, constant c, store". The "push address constant to stack" instruction is the only instruction that has one operand. All other instructions (including "load" and "store") have zero operands. -- 07:15, 4 October 2007 (UTC)

Thanks for your interest, but abbreviations taken literally can lead to all sorts of confusion! The "operand" these people are talking about are just some binary digits used to specify either the operand's constant value or its address (in main memory or in a register bank). These bits, along with some of the opcode-bits you mentioned, constitutes an operand specifier (or some term with similar semantic value), which has then probably been shortened to "operand", for convinence. There are no real "zero-operand" machines - not even The Minimal CISC; the fact that constants must be specified by shifting ones or zeroes into the stack-top does not make it "zero-operand". Also, its SUB-instruction takes two stacked operands and pushes the result back, thus not any more "zero-operand" than a conventional stack-machine. I sincerely hope you see my point! Best regards HenkeB 11:50, 6 October 2007 (UTC)
You seem to be saying that, since any useful operation must obviously apply to some operand (viewed in a semantic sense), it would therefore be meaningless to describe any machine performing such operations as "zero-operand". Yet people indeed use this term. Assuming they're not idiots, why would they do this? Presumably, because they aren't concerned that people might believe they mean the machines actually perform (useless) operations without operands. Instead, they draw a distinction between machines that generally do work by specifying explicit operands within most of their instructions, versus machines that generally do their work using implicit operands – found on a stack, in a pipeline, via a dataflow graph, or through some other mechanism that frequently omits specifying operands syntactically.
I take your point that useful operations have operands; and I agree that misusing terms is a bad idea. Yet I don't think this makes "zero operand" meaningless or wrong. I think you are simply looking at one feature of the issue through a very focused lens. At any rate, surely you will admit that the term "zero operand machine" is in common use, and that it refers to instruction set architectures that are conceptually and practically quite different from one- or n-operand instruction sets (differences that are very apparent when coding). Trevor Hanson 13:02, 6 October 2007 (UTC)
People also use double negations - "We don't need no education" - and all sorts of more or less unlogical language without being "idiots" (what do you imply really?). Should we encourage that kind of language simply because it is widely used? As I have already said, I belive we should instead strive after a consistent and coherent terminology, at least in science and technology! I'm fully aware, however, that most people don't care a bit, or even enjoy misleading terminology. That's why people that do care have to work that much harder.
Also, please don't imply that I wouldn't appreciate the distinction between stack machines and other architectures, or that I wouldn't admit the fact that the "zero operand" term is indeed frequently used in many circles. (I myself had barely heard of it before reading this article however.) HenkeB 14:56, 6 October 2007 (UTC)
Well, using your same logic, we would need to eliminate the normal use of terms like functional programming (because in practice all such languages DO permit side-effects), stateless transaction (because state is in fact managed by such systems in various ways), and perhaps even high level language (when referring to compilers that allow embedded assembler). I'm NOT trying to imply anything ridiculous about your position – you are correct in the distinctions you are making. But I am trying to use hyperbole to stress how it casts those you see as "misusing" terminology – but whom I expect are fully aware that such terms may *not* apply in a (shall we say) mathematical sense. It seems to me that such a view requires adherence to an unnecessarily literal usage of terminology. In most cases, we use descriptive terms like these to characterize the *majority* of cases, or to make a *conceptual* distinction – without necessarily meaning its premise is strictly true in every case. Or to put it another way, you seem to regard the term "zero operand" as an example of confusion or error by those who use it, whereas I see it as a description chosen deliberately (and not mistakenly) to make a distinction, rather than asserting an axiom. Trevor Hanson 19:52, 6 October 2007 (UTC)
I agree with Trevor Hanson that if we avoid using any potentially-confusing terms, it's hard to talk about the distinctions between these real machines. I'm a big fan of Bill Beaty ("Why is electricity so hard to understand?", "But how SHOULD we teach kids about 'electricity'?"). So I think that educational text (such as this encyclopedia article) should use terms that help people come to a proper understanding, and then later mention common (though potentially misleading) abbreviations used in the industry. Would it help our readers to use the term "operand specifier" in this article and in the addressing mode article, with a little footnote that in the industry it is usually shortened to "operand"[1]? So we would say things like "zero operand specifier machines (often called "zero operand machines" or "stack machines")". I see that the addressing mode article seems to neglect the "implicit"(x86 assembly language), also called "implied" (MOS Technology 6502), addressing mode. -- 07:58, 17 October 2007 (UTC)
I've added some mention of 'implicit' to the 'addressing mode' article. Thanks for pointing out this omission. Murray Langton 08:23, 18 October 2007 (UTC)

Family tree of ISAs[edit]

Hy, I'm looking for a "family tree" like the one for programing languages found here [2] Anyone have ever seen one? -- 09:15, 5 February 2007 (UTC)

You could try reading x86. -- mattb @ 2007-02-05T15:47Z


Should SWEET16 be added? It was a useful software implemented ISA created by Steve Wozniak. -- 20:41, 13 February 2007 (UTC)

Riscs Are usually THREE operand[edit]

Most RISC Processors actually use Three operands. Read the paper by John Cocke Listed under the IBM 801 article to see why. 21:37, 6 July 2007 (UTC)Fingal

Done. Good point. I've fixed the article to so it now claims that "most" RISC machines are three-operand, and included the article you mentioned, as a reference. But now I'm not so sure that's really correct. Processors with the highest unit volumes -- the Microchip PIC and the Atmel AVR -- while claimed to be "RISC" by their manufacturers, are one-operand and two-operand processors, respectively. Could we get a better reference? -- (talk) 08:39, 10 March 2008 (UTC)

discussion about spliting[edit]

I think there's difference between "instruction set" and "instruction set architecture". So there's need to split.Callmejosh (talk) 10:02, 28 August 2008 (UTC)

Would someone please give us a 2-sentence definition of "instruction set" and of "instruction set architecture", so the rest of us can see this difference? -- (talk) 03:51, 9 September 2008 (UTC)

Let me try-

instruction set:

A series of binary opcodes interpreted by the microprocessor for high levels of input and output. All software is compiled to binary instructions for a :specific (targeted) microprocessor (platform) the software architect intends the software to run on. Most, but not all Microprocessors, have a unique :instruction set (except, for example, both AMD and Intel microprocessors both utilizing the x86 instruction set). It is common for instruction sets to :rarely omit previously available instructions in new microprocessors, instead adding new and better optimized instructions and marking the older :instructions as "deprecated" in the documentation.

instruction set architecture:

The instruction set used by a specific microprocessor, utilized by software to run. It is common for modern operating systems to disallow direct access :to the ISA, instead letting user-mode software run in a virtual machine so permissions can be established and so the operating system can prevent damage :to the underlying hardware (usually by kernel panicking in Unix-like operating systems or showing a blue screen of death as in Microsoft Windows). This :is achieved by having the operating system provide system calls for software to access the hardware via the operating system's Hardware Abstraction :Layer.

Thats more than 2 sentences, but being a kernel hacker I really want these to be two separate articles. —Preceding unsigned comment added by (talk) 15:29, 5 October 2008 (UTC)

I agree with your description of instruction set, but your explanation of instruction set architecture is either wrong or misleading. The ISA consists of the instruction set and specifications of
  • the memory architecture (virtual memory, MMU, ...)
  • processor initialization
  • I/O
  • SMP
  • ...
Although user-mode programs usually do not need to know about the specifics, it is misleading to say thay they run in virtual machines. Furthermore, the protection enforced by the kernel is not supposed to avoid hardware damage (that's the job of the firmware and/or silicon logic) but to provide access protection between different user-mode programs.
Adrianwn (talk) 13:37, 6 October 2008 (UTC)
I agree that the instruction set is only a part of the instruction set architecture and those subjects should be treated in different articles. But the definitions for ISA proposed so far, are closer to the definition of Computer architecture, which is a different thing. By the way, the definition for ISA given in the Computer architecture article is pretty good: "Instruction set architecture, or ISA, is the abstract image of a computing system that is seen by a machine language (or assembly language) programmer, including the instruction set, memory address modes, processor registers, and address and data formats.". They cite the classic book by Hennessy/Patterson. This definition is also supported by a presentation by Dr. C. Chandra Sekhar[3].--Henrique Camargo (talk) 04:11, 31 December 2008 (UTC)

Incorrect classification of S/360 and S/370 implementations[edit]

This article lists IBM System/360 and S/370 as hardware implementations. Most models of the S/360 and S/370 were implemented with software in Read Only Storage (ROS) for the older models and Writable Control Store (WCS) for the newer models. The only hardware implementations were

  • 360/44
  • 360/75
  • 360/91
  • 360/95
  • 360/195
  • 370/195

All of these

  • 360/22
  • 360/25
  • 360/30
  • 360/40
  • 360/50
  • 360/65
  • 360/67
  • 360/85

and every S/370, 43xx and 30xx other than the 370/195 was microprogrammed. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:07, 22 November 2010 (UTC)

I think "hardware", in that context, is intended to include microcode; by "software" they appear to mean "software written in a regular programmer-accessible instruction set". Many of the instruction sets they list as implemented in "hardware" are, in part or in whole, implemented using microcode in most implementations (68K, x86, PDP-11, VAX, and, I think, Transputer). Yes, some microcode is "soft" in that it's, for example, read from a floppy disk into read/write memory, but, from the point of view of most programmers, it's different from "software". Guy Harris (talk) 09:29, 23 November 2010 (UTC)

Code density[edit]

There are a number of ways to improve code density; high code density does not imply that all of them were used. In particulary, high code density does not imply that there are special instructions for subroutine call and return, nor are such instructions part of the definition of CISC. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:31, 19 September 2012 (UTC)

Technically speaking, CISC and RISC processors have "special instructions for procedure call", but both the CISC System/360 and its successors, and many RISC processors, have procedure call instructions that just stuff the PC of the next instruction into a register and then jump, with, for example, stack-based procedure call sequences synthesized from that and other instructions, so a "push the return address onto the stack" instruction is not a sine qua non of CISC. Guy Harris (talk) 20:25, 19 September 2012 (UTC)

References needed[edit]

Surely someone other than Intel has written and published a slightly less product-specific discussion of the general concepts related to computer instruction sets? Better references are needed. --Wtshymanski (talk) 14:58, 9 October 2012 (UTC)

Details. What sentence, facts? Vague and useless comment.
Use inline-tags: too unspecific. And if you need more refs other than intel, specify where and the disputed facts. Tagremover (talk) 19:01, 9 October 2012 (UTC)
The whole article is the usual wikimess - we put a general tag at the top instead of tagging every single unsupported paragraph. It would be pointy of me to put a cn tag on each paragraph. There are no worthwhile references for anything said in the whole document. Instead we have a line or two from one or two manufacturer's parts catalog literature.
Taking the tag off to hide our shame isn't a very honest way to acknowledge the superficial nature of the references in this article. --Wtshymanski (talk) 19:39, 9 October 2012 (UTC)
ok, better, but not good. experts know when using words like "some": Wikipedia rules allow this. Tagremover (talk) 20:06, 9 October 2012 (UTC)

Separate data and instruction memories[edit]

In addition to machines such as the UNIVAC 1108, with separate I-bank and E-bank within the same physical memory, the machines designed to simulate a common architecture, e.g, most S/360 models, had a read-only storage for Microcodewith a different word size than that of the writable memory. I'm not sure how much detail belongs in the article on that point.Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:09, 18 January 2013 (UTC)

The separate I-bank and E-bank appear, from a quick read of the 1108 manual at, to just represent two segments (and, in fact, the manual speaks of the "I segment" and "D segment" on page 9 of section 9). They don't represent a Harvard-architecture-style separation of code and data memories (in fact, given that it sounds as if a given address is either an I-segment address or a D-segment address, so that there's only one range of addresses, it's less of a separation than, say, PDP-11 separate I and D space, where code references were within one 64KB address space, data references were within another 64KB address space, and there were special move instructions to allow reference to I-space locations as data). Guy Harris (talk) 20:41, 18 January 2013 (UTC)
The IBM microcode itself had different word sizes depending on the model; such microcode is irrelevant to the instruction set as seen by an IBM assembly language programmer. Hence it doesn't really fit in an article on 'Instruction set'. It would be more relevant to an article on how to implement an instruction set. Some of the DEC PDP-11 models had a similar arrangement, with model-specific microcode implementing a common instruction set across the various models. On some IBM models the microcode memory was actually read/write - you could load new microcode from an 8" floppy disk to upgrade the processor a little. Murray Langton (talk) 19:35, 18 January 2013 (UTC)
Agree. Microcode, unless user-microcodability is part of the architecture, is an implementation detail. Guy Harris (talk) 20:41, 18 January 2013 (UTC)
The engine running the microcode was a stored-program computer, with an instruction set. The application that the engine runs is not limited to simulating an instruction set. In fact, the IBM 3031 had two identical processors, one with microcode to simulate the S/370 instruction set and the second to drive the I/O equipment. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:13, 22 January 2013 (UTC)
Which means that it's irrelevant to the System/3x0 instruction set, given that one of the applications running on that engine's microinstruction set wasn't implementing the S/3x0 instruction set. Perhaps it would be interesting to separately discuss the microengines of microcoded processors, but, as those microinstruction sets aren't generally programmer-visible, perhaps it belongs in microcode instead - if the existing discussion there is insufficient. Guy Harris (talk) 22:38, 22 January 2013 (UTC)
The article is Instruction set, not System/3x0 Instruction set; the engine has an instruction set and the instruction word has a different size from the data word. Nor is the use of such engines limited to simulating the S/360; I worked on one that was programmed for processing seismic data. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:58, 23 January 2013 (UTC)
Your original statement was "the machines designed to simulate a common architecture, e.g, most S/360 models, had a read-only storage for Microcode with a different word size than that of the writable memory". Their internal instruction sets (not all of which were VLIW-style) might have been interesting in and of themselves as a separate item, but, in this article, are probably best discussed as Harvard architecture machines, just like, say, the the computer in the #1 ESS, or some DSPs, rather than as microengines that implement a given instruction set.

What is an instruction? Section or separate article needed[edit]

I see that the article for "Instruction (computer science)" was merged into this article in January 2011. I believe this was a mistake. Someone who is attempting to understand basic computer science needs to grasp the concept of a computer instruction before learning about sets of them or, shudder, being exposed to instruction set architecture in all its glory.

If you read the lead you will see there is no attempt at defining what an "instruction set" is a set of!

In general, we need to be able to link the word "instruction" to some text somewhere that defines that term and is understandable to such a person. I would prefer this be a separate article, but at the least this article should have a linkable section that clearly and simply defines what a computer instruction is (in traditional architecture).

In general I am of the school of Wikipedians that favors lots of concise articles on specific concepts over articles that try to cover a broad group of subjects, and that grow and grow and seem to gradually lose their coherence as they grow. (Not that this would apply to this article, mind you. :) )

So how can we solve this problem?

  • Resurrect "Instruction (computer science)" in very concise form with a link to this article.
  • Create a section in this article on "The machine instruction" (that starts out in baby steps).
  • Rewrite the lead to clearly define "instruction" in the process of defining what a set of them is.

Tell me what you think. Thanks! Frappyjohn (talk) 01:58, 1 March 2013 (UTC)


>>When some of the operands are given implicitly, the number of specified operands in an instruction is smaller than the arity of the operation. When a "destination operand" explicitly specifies the destination, the number of operand specifiers in an instruction is larger than the arity of the operation.<<

I understand the first sentence, but in the second sentence's case, shouldn't the number of operand specifiers be EQUAL as the arity? If not, why? SyP (talk) 11:57, 18 April 2013 (UTC)

I presume they mean that in "add r1,r2,r3" (assembly syntax there being "{op} {dest},{src},{src}") it's a binary operation, in that it's adding registers r2 and r3, but there's a third specifier indicating where to put the result, i.e. in register r1. If you have a two-operand add instruction, e.g. "add r1,r2" or "add r1,12[r2]", that's also a binary operation, in that it's adding registers r1 and r2 or adding r1 and the memory location 12 bytes after the address in r2, but it only has two operand specifiers, as the result is put into the same register as the left-hand operand of the addition operation. Guy Harris (talk) 17:36, 18 April 2013 (UTC)
Hopefully User:Wtshymanski's recent edits make this clearer. Guy Harris (talk) 17:39, 18 April 2013 (UTC)
It was a new word for me; but then I've had no formal computer science education, just a FORTRAN course. "Arity" is not a concept that gets mentioned in chip data sheets, but it's nice to have a link to the scientific/philosophical term. --Wtshymanski (talk) 17:48, 18 April 2013 (UTC)
Thank you for making it clear! Cheers, SyP (talk) 18:22, 18 April 2013 (UTC)
An example of arity three is the sum of products instruction available on some machines. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:00, 23 April 2013 (UTC)
Are you referring to fused multiply-add? Guy Harris (talk) 21:22, 23 April 2013 (UTC)
No; multiply-accumulate instructions go back farther than that, e.g., a 360/40 with a sum of products (SUMP) unit. Note that it need not include rounding the product.
There were also machine,s e.g., CDC STAR-100, with dot products instructions, multiplying pairs of numbers from two operands and adding the products to a third. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:59, 25 April 2013 (UTC)

Oocodes for 'software interrupt' - Design[edit]

The Design section mentions "Zilog Z80 uses the eight codes ". That is true, but the opcodes were originally part of the hardware interrupt on the Intel 8080. Since the Z80 added support for a vector table, the opcodes could be used for other purposes - like a tiny subroutine call. (Which several Microsoft BASICs made use of.) Wmdgus73 (talk) 04:11, 20 October 2013 (UTC)


What characterizes RISC is not the number of opcodes but their regularity and the simplicity of the operations. Specifically, in a RISC, instruction fetching, scheduling and execution take the same amount of time regardless of the opcode. Of course, cache misses and register conflicts can introduce delays, but those are a function of the execution profile rather than the individual opcode.

As an example, the IBM POWER microprocessors have a RISC architectue the IBM 7090 is a CISC, even though the 7090 has far fewer instructions. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:46, 3 December 2013 (UTC)

However, when a RISC instruction set includes such instructions as floating point multiply and divide, which many do, the idea of all RISC instructions taking the same amount of time to execute goes out the window. The processor, at the implementation level, may well have separate execution units for such instructions, so that subsequent independent operations are not delayed, but actual individual instruction execution times will still vary. Murray Langton (talk) 20:13, 3 December 2013 (UTC)
What characterizes RISC is, arguably, 1) the lack of register-to-memory arithmetic operations, so that RISC architectures are load-store architectures, 2) the lack of complex addressing modes, and 3) the lack of "complex instructions".
It's fairly easy to distinguish between load-store and non-load-store architectures.
For "complex addressing modes", the CISC S/360 and its successors are more like RISC than CISC, as the only addressing mode is base+index+displacement - no auto-increment or auto-decrement, no scaled indexing (unless that's snuck in recently), and even x86's addressing modes are essentially like S/360 with scaled indexing added, as opposed to the much more complicated addressing modes of the PDP-11, VAX, and 68k.
Even with z there is no scaled indexing, but I don't see that as a CISC/RISC issue. The z architecture still doesn't have auto-indexing or indirect addressing modes, which is more relevant to your distinction. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:28, 5 December 2013 (UTC)
Heck, PA-RISC not only has scaled indexing, it has post-increment and pre-decrement addressing modes ("base register modifications"), the last 4 letters of its name nonwithstanding. Guy Harris (talk) 03:27, 5 December 2013 (UTC)
For "complex instructions", S/360 had some, but its procedure call instructions (BAL/BALR/BAS/BASR) are really no more complex than those in RISC architectures - "move address of the instruction following a call into a register and jump". For complicated procedure call instructions, look at CALL in x86 or CALLS/CALLG in VAX. And S/360 had "load multiple"/"store multiple", but so do POWER/PowerPC/Power ISA.
"The case for the reduced instruction set computer", by Ditzel and Patterson, does mention floating point, in the context of memory speed vs. CPU speed:
"John Cocke says that the complexity began with the transition from the 701 to the 709 [Cocke80]. The 701 CPU was about ten times as fast as the core main memory; this made any primitives that were implemented as subroutines much slower than primitives that were instructions. Thus the floating point subroutines became part of the 709 architecture with dramatic gains. Making the 709 more complex resulted in an advance that made it more cost-effective than the 701. Since then, many "higher-level" instructions have been added to machines in an attempt to improve performance. Note that this trend began because of the imbalance in speeds; it is not clear that architects have asked themselves whether this imbalance still holds for their designs."
although RISC ISAs largely included floating-point from Day One, so perhaps floating-point, unlike, say, string processing and decimal arithmetic, is something worth having in the instruction set regardless of memory speeds. Most of the examples of instruction-set complexity they cite come from the VAX; some others come from S/3x0, but those are the string and decimal instructions, mentioned in a footnote:
"Peuto and Shustek observed that the complex decimal and character instructions of the IBM and Amdahl computers generally resulted in poorer performance in the high end models."
(and I have the impression that in late S/390 and in z/Architecture implementations, those are done in millicode, so they're basically done as fast traps/procedure calls to machine-language subroutines, possibly using some special model-dependent instructions available only in millicode; in the RISC AS/400-and-successor models, I think the TI-to-machine-code translator generates code using simpler instructions, albeit with, I think, some simple assist instructions to, for example, speed up excess-6 decimal arithmetic).
Every time that IBM designs a new processor it does a new analysis of the performance tradeoffs, including the optimal combination of circuitry, microcode and millicode. Some instructions have gone back and forth over the generations. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:28, 5 December 2013 (UTC)
I think the RISC-vs.-CISC tradeoffs have changed somewhat since the mid-to-late-1980's, so RISCs got more complex and CISC processors went down paths that removed some RISC advantages (for example, x86, starting with Pentium Pro, and z/Architecture processors both split instructions into micro-ops that can be scheduled independently, so register-to-memory arithmetic instructions don't get in the way), and that some of the CISCier bits of some architectures (68k, PDP-11, VAX) disappeared as those architectures did, leaving behind CISCs that lacked many of them (x86 and S/3x0-z/Architecture don't have complicated addressing modes of the sort that the PDP-11, 68k, and VAX did), and even in cases where complexity is hard to remove for compatibility reasons (x86 CALL) I think they special-cased the simple versions and the more complex versions aren't used much any more. Guy Harris (talk) 22:49, 3 December 2013 (UTC)
OTOH, IBM added the program call (PC) to the original architecture, and it is much more complicated than the CICSy bits that disappeared with the older architectures you mentioned. Shmuel (Seymour J.) Metz Username:Chatul (talk)
So what is PC used for? General subroutine calls, or is that still done with BAL/BALR/BAS/BASR? (It's a bit complex, but I'm not sure it's any more complex than x86 CALL.) Guy Harris (talk) 03:29, 5 December 2013 (UTC)
PC is used to call routines in a different address space or with a different privilege level; think of it as a cross-ring call on steroids. BASSM and the like are still used for more conventional subroutine calls. Note that the linkage stack used by PC is in protected storage and is distinct from the save area chain used for normal linkage. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:37, 5 December 2013 (UTC)

How is sequential instruction processing related to the Von Neumann architecture?[edit]

The article says: "More complex operations are built up by combining these simple instructions, which (in a von Neumann architecture) are executed sequentially, or as otherwise directed by control flow instructions." Can someone explain how the sequential execution of instructions is related to the Von Neumann architecture? Couldn't the Harvard architecture execute the instructions one-by-one too? Maybe we should refactor this sentence... It's also unsourced. Sofia Koutsouveli (talk) 15:58, 22 March 2014 (UTC)

Possibly to distinguish a conventional architecture with a single opcode field in an instruction from a VLIW computer with multiple opcode fields in an instruction. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:52, 24 March 2014 (UTC)
GIven that the machine on which I'm typing this has a superscalar out-of-order processor (well, four of them on the CPU chip...), I guess it's not a von Neumann-architecture machine, then. :-)
Perhaps we should just 1) drop the "in a von Neumann architecture" and 2) replace "sequentially" with "in the sequence in which they are stored in memory"; "as otherwise directed by control flow instructions" sounds as if it's referring to deviations from a pure ordering of instructions by their memory addresses. Guy Harris (talk) 21:06, 24 March 2014 (UTC)
Well, in the IBM 650 an instruction has a D address and an I address, with the I address being the address of the next instruction except in the case of a successful conditional branch. Would you not classify the 650 as a von Neumann architecture? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:56, 26 March 2014 (UTC)
Then we need to find another way to describe the sequence of instructions (or to label each instruction in the 650's instruction set as a control flow instruction :-)). Guy Harris (talk) 18:40, 26 March 2014 (UTC)
I've dropped the "in a von Neumann architecture" note. Guy Harris (talk) 18:42, 26 March 2014 (UTC)