Talk:Instruction set architecture

Instruction Encoding

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 46.116.12.41 (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 46.116.98.85 (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)

Intro

I have included a simple definition for mortals.

Link to this page from this page for "instruction"

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 84.111.72.161 (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

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 209.226.94.111 (talk • contribs) 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) 81.100.66.178 (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

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. --68.0.120.35 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. --70.130.44.41 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)

There's another problem with the text; the STORE instruction may itself be a 0-operand instruction. For instance, on the Burroughs B5000, only Descriptor Call, Literal and Operand Call syllables have operands; a STORE uses the top two locations on the stack. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:32, 28 July 2014 (UTC)

Family tree of ISAs

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

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

SWEET16

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

Riscs Are usually THREE operand

Most RISC Processors actually use Three operands. Read the paper by John Cocke Listed under the IBM 801 article to see why. 66.73.48.200 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? --68.0.124.33 (talk) 08:39, 10 March 2008 (UTC)

discussion about spliting

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? --68.0.124.33 (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 70.89.148.13 (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)

Agree.

Incorrect classification of S/360 and S/370 implementations

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

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

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

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 bitsavers.org, 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

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)

Arity

>>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

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)

RISC

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?

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)

permission to use an instruction set

See the discussion at talk:processor design#permission to use an instruction set.

Where to put neural networking instructions

I understand their coming to x86 (AVX-512?), not sure if they should fall under "Complex instructions"-heading..

I just find them intriguing. No matter where they should be put, I think they should be included..

[Also not mainstream yet are instructions for complex numbers (can you think of other non-ordinary not included here?). Since can be broken down, I do not really expect them in RISCs; nor x86 really (e.g. in above). I'm aware of some designs for logaritmic number systems [for them], but I guess in no actually used chips? Complex numbers can be used for neural networks.. while often only real-valued used [or with such instructions..].] comp.arch (talk) 15:33, 28 March 2017 (UTC)

I think AVX-512 instructions, whether they have anything to do with neural networking, would be SIMD instructions, like the other AVX instructions.

These days, computational instructions are added if they allow more stuff to be done in a single CPU cycle; if you had a "complex add" instruction that added the real and imaginary parts in parallel, using separate ALUs, that might be considered for inclusion, but a "complex add" that adds the real parts in one cycle and the imaginary parts in the next cycle would probably be omitted unless it produced a large-enough-to-be-worth-the-effort reduction in code size, and I suspect it probably wouldn't. Guy Harris (talk) 18:46, 28 March 2017 (UTC)

"complex" add (meaning complex-valued here..) is of course just SIMD add. I was thinking of something like multiplication (or even divide..). We have FMA, that is of course complex in the other sense (even only either addition or multiplaction); and FMA can be used for complex-valued multiplaction. For however polar form, it's only SIMD add.. comp.arch (talk) 08:45, 29 March 2017 (UTC)

Regarding the definitions of ISA and instruction set and the article's title

The article's lead presently says:

An instruction set, with its instruction set architecture (ISA), is the interface between a computer's software and its hardware, and thereby enables the independent development of these two computing realms; it defines the valid instructions that a machine may execute.

It is the part of the computer architecture related to programming, including the native data types, instructions, registers, addressing modes, memory architecture, interrupt and exception handling, and external I/O. An ISA includes a specification of the set of opcodes (machine language), and the native commands implemented by a particular processor.

This has several problems:

• Is an "instruction set" something that has an "instruction set architecture", or is an "instruction set" something that an "instruction set architecture" has? The latter is correct. The article should note that some ISAs offer several instruction sets. These ISAs consider an "instruction set" to be something that the ISA offers.
• What does "independent development" mean? I think the article intends to mean that software written in a high-level programming language can be compiled for several different ISAs. If so, it can be stated more clearly.
• What are "computing realms"? I suspect this is just meaningless purple prose.
• The article states that "instruction set" (or ISA) is a part of "computer architecture" (that is related to programming). This is wrong. "Computer architecture" can be a synonym of "ISA". In fact, when the notion of an ISA was first conceived during the development of IBM's System/360 family, Amdahl, Blaauw, and Brooks defined "computer architecture" as: "...the structure of a computer that a machine language programmer must understand to write a correct (timing independent) program for that machine." The article should quote this definition, note that "architecture" is synonymous with ISA, and that "ISA" is a synonym that was coined after "computer architecture" and its contraction "architecture".
• There is a list of what an ISA defines. The problem with this is that it gives the impression that these are things that an ISA must define. Some ISAs do not specify some of these items as completely as others. There is much variability amongst ISAs in this regard.
• Is the article trying to equate "opcodes" to "machine language"? Opcodes are a part of an instruction, and the defined instructions constitute the machine language.
• What are the "native commands" that a particular processor implements? "Native commands" sounds like the microinstruction defined by the architecture of a microengine, but this is not defined by the ISA for obvious reasons!

This leads to the article's title. Given the history of the term "ISA" and that in some ISAs, an "instruction set" is a component of the ISA, it makes more sense that the article be titled "Instruction set architecture", since this title is capable of encompassing all possible definitions, whereas "Instruction set" cannot. 50504F (talk) 06:50, 9 May 2017 (UTC)

"Is an "instruction set" something that has an "instruction set architecture", or is an "instruction set" something that an "instruction set architecture" has? The latter is correct." [citation needed] Guy Harris (talk) 07:13, 9 May 2017 (UTC)

Yup, this question does really resemble to Chicken or the egg. Maybe the developers first developed the whole computing system without even considering the architecture at all. They had the Instruction Sets first, and gradually the architecture is abstracted from the actual instruction sets, such as the architecture of Intel 80x86 or 80x87. Some developers go an up-side-down way, they did the research the current architectures (ISAs) first, and devised some an innovated or just extended architecture, such as IA-64 and AMD64 respectively. The architecture of 80x87 is distinct from the one of 80x86, as Intel put those two processors onto the same silicon die, they both are eventually fused together, and build up the common architecture of 80x86 processors. Intel later name the architecture of such processors as IA-32. As a friend and opponent of Intel, AMD played an important role, making ways for Intel (kicking out other opponents). The IA-32 architecture is mature, powerful, and strong enough to deal with then-current computing needs. Expanding it merely from 32-bit to 64-bit could not gain too much as expected from the 8086 to 80286, and from 80286 to 80386. They understood this, and such related information could obtained from the books on Itanium. Intel want to prolong the life of IA-32, and they know if so, it must need to absorb nutrients from the outside world rather than merely staying in the hotbed inside Intel. They left a larger room to AMD, when they were absorbing "nutrients" from IA-64 architecture. Then the final product of AMD on the research and development of 64-bit on IA-32 happen to change, comparing the original architecture. This 64-bit extended architecture eventually turned to be the comprising part of x86-64 architecture, in the form of 64-bit extension of x86. This is a double-win-win product, with which Intel realised its purpose on the prolong of IA-32, and AMD did not fear to lose the market if this 64-bit architecture were unsuccessful. From a specific instruction set to abstract to its architecture is the job of architect (computer), but as a learner, one should learn its instruction set from its instruction set architecture. Wikipedians should stand on side of learners, so I go agree with that an "instruction set architecture" possesses its own "instruction set", rather than vice versa. — Preceding unsigned comment added by 119.53.116.164 (talk) 12:45, 9 May 2017 (UTC)

Citations supporting the claim that instruction set is a subtopic of instruction set architecture were requested. Well, here they are:

David Patterson, John L. Hennessy: Computer Organization and Design: The Hardware/Software Interface, 5th ed.

Page 22 states:

One of the most important abstractions is the interface between the hardware and the lowest-level software. Because of its importance, it is given a special name: the instruction set architecture, or simply architecture, of a computer.

Page 22 gives a dictionary definition of "instruction set architecture":

(Also called architecture). An abstract interface between the hardware and the lowest-level software that encompasses all the information necessary to write a machine language program that will run correctly, including instructions, registers, memory access, and so on.

Page 62 introduces the concept of an instruction set in prose:

To command a computer's hardware, you must speak its language. The words of a computer's language are called instructions, and its vocabulary is called an instruction set.

Page 62 gives a dictionary definition of "instruction set":

The vocabulary of commands understood by a given architecture.

Steve Furber: ARM system-on-chip architecture, 2nd ed.

Page 2 states:

Computer architecture describes the user's view of a computer. The instruction set, visible registers, memory management table structures and exception handling model are all part of the architecture.

William Stallings: Computer Organization and Architecture: Designing for Performance, 9th ed.

Page 7 states:

Computer architecture refers to those attributes that have a direct impact on the logical execution of a program. ... Examples of architectural attributes include the instruction set...

Citations aside, I looked at the article history today to rule out the possibility that accidental mistakes were responsible for the article's present state. I discovered that the article did not claim that instruction sets have instruction set architectures until this edit from 1 February 2017. The accompanying edit summary suggested that further editing to improve factual accuracy and clarity were required. I concur. In fact, in between this edit and the second version of this article from 15 April 2002, the lead said:

An instruction set, or instruction set architecture (ISA)...

This means that the article never claimed that instruction sets have instruction set architectures for around 15 years!

On a separate note, I've noticed that the lead's implies that ISAs exist to enable independent development of software and hardware. This is wrong. ISAs exist to enable the same software to run on a range of computers that vary in performance, size, price, etc. 50504F (talk) 06:00, 10 May 2017 (UTC)

Not all of the references speak of an instruction set architecture; they just say "architecture". That's probably a good idea, given that, for example, the Furber reference lists "the instruction set, visible registers, memory management table structures and exception handling model" as part of the architecture, so it's more than just the architecture of the instruction set.

The ARMv8-A manual talks about multiple levels of architecture - it speaks of "the ARM architecture v8, ARMv8", as well as "the AArch64 Application Level Architecture" and "the AArch32 Application Level Architecture". It does speak of "the instruction set architecture" in "A1.7.6 The Statistical Profiling Extension" - "The Statistical Profiling Extension provides a non-invasive method of sampling software and hardware using randomized sampling of either architectural instructions, as defined by the instruction set architecture, or by microarchitectural operations." - but doesn't mention it elsewhere. ARMv8-A has three separate instruction sets - A64, A32, and T32.

The Power ISA 3.0 manual says that a processor is "The hardware component that implements the instruction set, storage model, and other facilities defined in the Power ISA architecture, and executes the instructions specified in a program."

So it's somewhat unfortunate that the term "instruction set architecture" has become common, as it's a term for something that includes more than just the instruction set; it's as if the term "plumbing architecture" were used to describe the architecture of a house. Sadly, we're stuck with it, but we should probably make it clear that "instruction set architecture" is not the only term used for the concept, and that it can cover more than just the instruction set, the name nonwithstanding.

Perhaps we should have a page "instruction set architecture" to cover the overriding notion of an "instruction set" architecture, making it clear that it can cover more than just the instruction set, pointing to this page when it speaks of the "instruction set" as being part of the "instruction set architecture". ("Computer architecture" already has a page, covering a much broader topic than just instruction set architectures.) Guy Harris (talk) 18:03, 10 May 2017 (UTC)

When the term "instruction set architecture" (ISA) is encountered, are there cases where this is interpreted to mean the architecture of an instruction set? I don't think it is the correct definition of the term "ISA" (and I've never encountered such a definition), but it does seem plausible that this could be the case. If this is what "ISA" is sometimes interpreted to mean, then does it contribute towards an understanding as to why the lexicon is frequently used inconsistently with reliable sources, such as the provided references?

Regarding whether there should be one or two articles, if we are to work from the view that an instruction set is a part of an ISA (a subtopic), then having two articles would be "difficult". This is because instruction set issues are so closely related to architecture (and it can be said the the opposite is equally true), both articles would almost certainly end up being redundant to each other. I think my original proposal, that "instruction set" be treated as a subtopic of ISA is best. This is how many textbooks (such as those cited here) are written. 50504F (talk) 07:38, 11 May 2017 (UTC)

If this page becomes the "instruction set architecture" page, wth that name, it should note that there's more to an ISA than just the instruction set, and should at least mention memory mapping, exception handling, etc. - i.e., its discussion of instruction set issues, which, at this point, is pretty much all this page discusses - should be a subtopic of this page. Perhaps its discussion of memory mapping would largely just point to the memory management unit page, but it should at least note that many ISAs specify, to some degree, how the MMU works.

(And, of course, the lede should be changed to speak separately of "instruction set architectures" and "instruction sets", making it clear that the latter is one component of the former.) Guy Harris (talk) 08:14, 11 May 2017 (UTC)

I've rewritten the the lead to fix the issues raised. It's much better than before, but given the broad scope and sophistication of the topic, I suspect that the lead is still imperfect. A review of the edits would be very helpful. 50504F (talk) 05:42, 17 May 2017 (UTC)

The lead is heavily based on the aspect from programmer, rather than an architect (computer), abstract and hollow

"An instruction set architecture (ISA) is an abstract model of a computer that defines everything a machine language programmer needs to know in order to write a machine language program for that computer. It is also referred to as architecture or computer architecture."

This definition is heavily based on definitions of others, such as machine language, programmer and this everything in your words. It is no good for the definition of ISA. 221.9.19.140 (talk) 09:36, 17 May 2017 (UTC)