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 section as of 29 May 2017

The lead section (which I'm mostly responsible for), as of 29 May 2017, says:

An instruction set architecture (ISA) is an abstract model of a computer. It is also referred to as architecture or computer architecture. A realization of an ISA is called an implementation. An ISA permits multiple implementations that may vary in performance, physical size, and monetary cost (among other things); because the ISA serves as the interface between software and hardware. Software that has been written for an ISA can run on different implementations of the same ISA. This has enabled binary compatibility between different generations of computers to be easily achieved, and the development of computer families. Both of these developments have helped to lower the cost of computers and to increase their applicability. For these reasons, the ISA is one of the most important abstractions in computing today.

An ISA defines everything a machine language programmer needs to know in order to program a computer. What an ISA defines differs between ISAs; in general, ISAs define the supported data types, what state there is (such as the main memory and registers) and their semantics (such as the memory consistency and addressing modes), the instruction set (the set of machine instructions that comprises a computer's machine language), and the input/output model.

Reading the lead section leads to see two possible issues:

• The lead section attempts to cover two "types" of ISAs implicitly: those of computers that weren't designed from a pre-existing ISA specification and those that were. Does the article adequately distinguish between the two, and are there parts that are only true for one of the "types' of ISA?
• The lead section states that an ISA defines everything a machine language programmer needs to know in oder to program a computer. This isn't technically wrong, but since computers aren't programmed in machine language anymore (perhaps with a few exceptions), is this statement misleading because it omits the relationship between ISAs and assemblers/compilers?

Feedback would be helpful. 50504F (talk) 06:40, 29 May 2017 (UTC)

There are two categories of programmer who need to know the ISA pretty well in order to program: (first) assembly language programmers, since there is usually a fairly close (mainly one-to-one) relationship between what they write and what machine code is produced; (second) compiler writers, since they have to generate code in accordance with the ISA (could be binary machine code, or it could be assembler instructions). Murray Langton (talk) 06:58, 29 May 2017 (UTC)

I'd say that the difference between machine-language programming and assembly-language programming isn't big enough to matter here (you might not have to know the encoding of opcodes, addressing modes, etc., if you program in assembly-language, but you do have to know what instructions are available, what registers are available, etc.). You could change "machine-language programmer" to "assembly-language programmer".

I would, however, say it should mention compilers - and assemblers, as you need to get the aforementioned encodings correctly, so that the ISA is what assembly-language programmers, writers of assemblers, and writers of compilers need to know. Guy Harris (talk) 09:05, 29 May 2017 (UTC)

I think the phrase "serves as the interface between software and hardware" will simply be puzzling to the general reader. Jeh (talk) 10:33, 29 May 2017 (UTC)

jeh's idea

Here's my first pass at an improvement. It probably contains much detail that is already in the article body; I haven't checked. I haven't been careful about quote marks vs italics, or other details of wikimarkup, either.

The challenge that must be met by the lede here is that many of the terms used to describe the concept of "ISA" will, like "ISA", also be unfamiliar to the general reader, and we shouldn't depend on WLs for everything.

proposed text

A computer's instruction set architecture (ISA) (also referred to as "instruction set", or less rigorously, "computer architecture" or simply "architecture") is a functional description of a computer's central processing unit (CPU). It is an "abstract model" of a computer's CPU, in that it only provides a functional description, with no requirements of how those functions are to be implemented.

The primary role of an ISA is to define the "machine language" in which programs for the computer are coded. This language is usually, in the architecture specification, described using binary, octal, or hexadecimal notation. For example, an instruction to "move" data from one place to the other might be coded in the computer's memory as D0 (hexadecimal). The ISA defines this coding and describes exactly what the processor will do when it encounters this instruction, including all side effects and any exception conditions that may arise. The ISA provides this definition for each of the instructions the CPU can perform, hence defining the CPU's "instruction set". Examples of instructions implemented by most computers include "move", "add", "subtract", "call" (for a procedure or subroutine), "compare", and "branch" or "jump" instructions. These instructions are comparable to verbs, specifically directives, in a natural language.

An ISA defines many other aspects of the CPU's machine language. These include the types of data that the instructions can operate on, and how to refer to the various types of storage in which the data can reside (such as registers and memory). In terms of the instruction set these are generally called "operands". For operands in main memory, the ISA may provide a number of different "addressing modes" by which memory addresses can be specified. Finally, an ISA usually defines various elements of the computer called, for example, "system programming" features. These features are usually not accessed directly by application programs, but are essential to the function of operating systems. The machine language is closely associated with "assembly language", and developers of programming tools such as assemblers, compilers, and debuggers require knowledge of the machine language.

A realization of an ISA is called an implementation. Prior to the development of formal ISA specifications the computer's architecture was usually designed by the hardware engineers along with the first (sometimes only) implementation; the ISA was whatever resulted. By contrast, a formal ISA specification permits multiple implementations that may vary in performance, physical size, and monetary cost (among other things). Because the ISA is common to all such implementations, software that comports to the ISA can run on different implementations of the same ISA. This has enabled software compatibility between different models and even different generations of computers. These developments have helped to lower the cost of computers and to increase their applicability. For these reasons, the development of formal ISAs was extremely important step in the history of computers.

commentary

If you want to make changes rather than starting from scratch yourself, simply edit the above section (and btw I think embedded inline sigs for each change would be pointless). But if you do that I may change them back or riff further on your ideas. Or, copy it into your own subsection and edit there if it seems better to do that. I'm not saying the lede has to be based on this, even a little - this is just my current thinking about what it should say.

Jeh (talk) 19:05, 29 May 2017 (UTC)

other text

...includes bits from my original version that I've since culled. May or may not have a place in the rest of the article.

other "architectures"

The word "architecture" may also be used in terms like "microarchitecture", "memory architecture", and so on, which refer to other descriptions of a computer's organization. "instruction set architecture" is specific to the topic of this article, the definition of the CPU's machine language.

Relationship to programming languages

Very little programming is done directly in machine language, but each ISA is normally associated with a symbolic language called an "assembly language". Assembly language has close to a one-to-one relationship with the elements of the machine language, but is far easier for programmers to write and to understand. In assembly language the instructions defined by the ISA are usually represented by short words or abbreviations of words, such as "move" or "mov" for the "move" operation. These are called "mnemonics". Assembly language is converted to machine language by a program called an assembler. An ISA specification may suggest the mnemonics for each of the ISA's instructions, or may leave these up to the implementor of the assembler.

Most programmers work not in assembly language but in any of several higher-level languages; these are converted to the machine language via a compiler. Programmers who develop either assemblers or compilers, or other programming tools such as debuggers, must be familiar with the CPU's ISA to write these programs. Knowledge of the computer's ISA is also essential in low-level debugging of both application programs and operating system code.

S/360

One of the earliest and most influential formal ISA specifications was the one IBM released describing its then-new "System/360" line of commputer, entitled IBM System/360 Principles of Operation. It defined an architecture that was first implemented by machines spanning performance and memory size ranges of approximately ten to one. This ISA was later extended to define the IBM System/370 ISA and then the IBM Z-architecture, each time with the previous architecture included as a subset. Because of this, programs that ran on the smallest of the original IBM System/360 models can run unchanged on the latest Z-architecture machines. Architectures that are extended this way are said to be backwards compatible in that implementations of the later version of the architecture remain compatible with programs coded to the earlier versions. Jeh (talk) 23:46, 29 May 2017 (UTC)

Well, even more, S/360 is considered (by many, and especially IBM) to be the first architecture. That is, the first designed before the computer (s) were designed. Previously, the computer would be built, and then its instruction set documented. Often changes were made to adapt to the technology, or, for example, opcodes selected to make decoding easier. S/360 was designed, and then (about) five different models started to be built. Any changes would apply to all of them, and so were much less likely to be approved. The VAX architecture book mentions this, though theirs didn't last quite as long. Gah4 (talk) 23:10, 10 June 2021 (UTC)

Re. Jeh's proposed version

I think this version is a much gentler and more comprehensive overview of the topic than mine. I would endorse a copyedited version of it. I currently have two remarks about the proposed version:

• The proposed version makes a distinction between a computer and CPU, which I don't think is completely accurate because the ISA can have implications for computer organizational issues outside of the CPU. Such issues are numerous, but could pertain to the memory system, I/O (such as interrupts, I/O channels, etc.), and even multiprocessing (beyond memory ordering) such as system interconnects. I think it's safe of omit this distinction without compromising accessibility.
• The proposed version assumes that there is a part of the ISA that is for the user, and some other for the OS. While this true for complex computers, its not true for older (historical) and simple computers (such as microcontrollers). This should be clarified.

50504F (talk) 07:44, 30 May 2017 (UTC)

a) Nice of you to say, thanks!

b) Both remarks are well taken, but I think the first blurs the line between the ISA and the computer's overall hardware architecture. I think the point you raised in the second should probably be addressed by leaving that distinction out of the lede, omitting the mention of "system programming" features altogether. I'll take a stab at this - if no one else does - after my next sleep.

Jeh (talk) 10:31, 30 May 2017 (UTC)

The line between the ISA and hardware architecture is a bit blurry, in that some aspects of the ISA involve the CPU's connection to I/O devices (e.g. System/3x0 data channels, the PDP-11 I/O page, VAX I/O space, x86 I/O instructions, etc.) or the cache (instructions with cache hints or that bypass the cache, for example).

The "system programming" features are part of the ISA, so they should at least be mentioned, even if we don't say "these are mostly for system software".

Or, to put it another way, there's more to the instruction set architecture than the instruction set - and that's a point worth mentioning, as far as I'm concerned.

Also, at some point we should note that not all ISAs correspond to a CPU's hardware/microcode. Until chips such as picoJava, the Java bytecode instruction set architecture wasn't for a physical CPU, I don't think any processor directly executes the Common Language Infrastructure bytecode, and the System/38 and IBM i "machine interface" instruction set (see here) is never executed directly, it's translated into the actual machine instruction set (IMPI in S/38 and older AS/400 machines, a Power ISA-based instruction set in later machines) and executed. Nevertheless, they're the target of compilers for the Java/CLI/IBM i platforms. Guy Harris (talk) 19:35, 30 May 2017 (UTC)

… is a set of commands/micro-operations

Couldn't we just write that instead of the current "… is an abstract model of a computer". User:ScotXW^t@lk 19:10, 14 July 2017 (UTC)

Why not just "operations"? "Commands" could be confused with command-line commands, and "micro-operations" could suggest individual microinstructions on a microcoded processor or uops on a processor that breaks instructions into uops and schedules and executes those uops. Guy Harris (talk) 19:24, 14 July 2017 (UTC)

DSP citation

There is a {{cn}} related to DSPs and Harvard architecture which, as usual, doesn't say what it wants cited. Most, but maybe not all, DSPs are Harvard architecture. That is easy to find out. Most have a multiply-accumulate, that is easy to find out. Do all do it in one cycle? Maybe they pipeline it, so one can start every cycle. Maybe some take two cycles. Harvard architecture is also convenient, even when speed isn't important, when instructions are in ROM (or EPROM or flash), and RAM is small (and in RAM). That is true for many modern microcontrollers. But yes for DSPs, having separate data bus allows instructions and data to fetch at the same time. That is likely documented, but the thoughts of the designer may be harder to find. So, what exactly needs to be cited? Gah4 (talk) 23:15, 10 June 2021 (UTC)

Ask the person who made this edit. Or just remove the CN, at this point I don't care. Guy Harris (talk) 23:23, 10 June 2021 (UTC)

Issue regarding register pressure

As written under the section register pressure

While embedded instruction sets [...] suffer from extremely high register pressure because they have small register sets, general-purpose RISC ISAs [...] enjoy low register pressure

doesn't sound right. Afaik general purpose ISAs should not suffer as much because the offload of data to primary storage shouldn't be as penalising. Spillage should be easier to handle in a general purpose risc compared to an embedded system. Furthermore non embedded systems tend to have a higher register number, decreasing the likelyhood of spillage in the first place. But there seems to be no reason for low register pressure and therefore reducing the utilisation of registers in favour of primary storage. Hu1buerger (talk) 19:58, 9 July 2021 (UTC)

Maybe overgeneralizing, but RISC architectures tend to have more registers. Also, some like SPARC have a built-in register stack (meaning even more physical registers). Embedded instruction sets, that is in processors designed for and commonly used in embedded systems, often have fewer registers. However, most often smaller programs are written for embedded processors, which might make up for the difference. Register pressure is only a problem for programs large enough to need more registers. Gah4 (talk) 22:34, 9 July 2021 (UTC)

Almost all of the CISC systems that I'm aware of all suffer from register pressure. This includes machines from, e.g., CDC, DEC, IBM, Honeywell, RCA. This was especially true through the mid 1960s, when most machines had only one accumulator and a small number of index registers.

In the mid 1960s and later there were CISC machines with more accumulators, but they generally also served as index and even base registers, making a set of 16 more cramped than it might seem at first glance. Notable exceptions were the STAR 100, which had 256 registers, and the successor machines from ETA. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:11, 20 November 2023 (UTC)

How many registers is enough to make register pressure uncommon? If 16 isn't enough, i.e. S/3x0 is a sufferer froom register pressure, note that this means that the 32-bit ARM RISC ISA, which also has 16 registers, probably also suffers the same level of register pressure, but that x86 processors with the Advanced Performance Extensions, which (will?) have 32 registers, would probably suffer no more register pressure than most RISC ISAs. z/Architecture's instructions that operate on the upper 32 bits of GPRs might also reduce register pressure to some degree (I'm guessing that was the intent), if you're doing a significant amount of 32-bit arithmetic. So it's not a simple CISC vs. RISC question; the "enough registers" number would decide which CISC and RISC ISAs have "enoguh registers". Guy Harris (talk) 20:18, 21 November 2023 (UTC)

It depends very much on the architecture. As an example, the DEC 36-bit machines, e.g., PDP-6, PDP-10, have 16 registers and the IBM System/360 has 16 general registers, but on the S/360 the GRs also serve as base registers, leading to more pressure. The introduction of relative and long displacement instructions on IBM z/Architecture reduces the register pressure, although, IMHO, 16 is still not enough.

It also depends on which registers you are talking about. The floating point registers on the S/360 do not serve any other purposes, and the expansion from 4 to 16 probably eliminated most FP register pressure. However, the later overlaying of the first 16 vector registers on the FP registers may have increased the FP register pressure. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:56, 22 November 2023 (UTC)

A different issue is the text This is due to the many addressing modes and optimizations (such as sub-register addressing, memory operands in ALU instructions, absolute addressing, PC-relative addressing, and register-to-register spills) that CISC ISAs offer. While it may be true for the Intel 80xx family and its clones, it is most decidedly not true for CISCs in general. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:04, 21 November 2023 (UTC)

If we look at the source for that claim, which is comparing only three instruction sets - Thumb, x86-64, and Alpha, so it is making no claims about "CISC ISAs" in general, it says, on page 123:

"sub-register addressing" "allows programmers to address 48 sub-registers to store/operate on smaller data types, which can be further exploited by aggressive sub-register coalescing strategies to reduce the number of register spills". It's presumably referring to x86-64 allowing code to access the low-order bytes of all 16 GPRs, the low-order 16 bits of all 16 GPRs, and the low-order 32 bits of all GPRs in instructions with a REX prefix. That does not increase the number of GPRs; for example, if you're using AL to store a 1-byte value, you can't use the remaining bits in RAX for any other purpose, so it's not as if you have 48 more registers to use. z/Architecture's "upper half" instructions more obviously reduce register pressure, as you can stuff separate two 32-bit values in a single GPR.

"Absolute memory addressing" "allows instructions to directly access memory operands, eliminating the need to allocate registers for temporary storage of loaded values". That appears to mean the exact same thing as "memory operands in ALU instructions", so I'm not sure what "absolute addressing" refers to; perhaps the editor who wrote that quote was confused. In any case, if "RISC" is interpreted as load-store architecture, and "(modern) CISC" is interpreted as "not load-store architecture", then "memory operands in ALU instructions"/"absolute memory addressing" is absent from all RISC architectures and present in all (modern) CISC architectures ("modern" meaning "in the era with processors being binary and having multiple GPRs through which most (non-decimal) arithmetic takes place", i.e. S/3x0, PDP-6/PDP-10, PDP-11, VAX, 68k, x86, etc.). That probably somewhat reduces register pressure, as you don't need to put all operands in registers, but I think setting one register aside, in a load-store architecture, as the "memory data register", so that a CISC instruction "add memory operand O to register R" would turn into RISC instructions "load memory operand O to register MDR; add register MDR to register R and put the result in register R". However, that just reduces register pressure by one register.

"Program counter relative addressing" "enables position-independent code without the overhead (both in performance and allocated registers) of a Global Offset Table." I'll have to look at that in more detail, but, well, draft 0.99.6 of the x86-64 ABI mentions the Global Offset Table (GOT) on page 77; perhaps the people who developed that ABI didn't get the memo, or maybe later versions got rid of it, or maybe it doesn't have to be used as much as with ISAs that don't have PC-relative addressing. Then again, instruction sets that have a procedure call instruction that puts the return address into a register can be used, at the cost of USING :-) a register, to provide something similar to PC-relative addressing for position-independent code. That's used in RISC ABIs as well as the ABI for a CISC ISA that lacks arbitrary PC-relative instruction operands. Perhaps what they mean is that PC-relative addressing for operands means you don't need to use a GPR loaded with a procedure call instruction to refer to the GOT, again reducing memory consumption by one register. (As I remember from being at Sun when the SunOS 4.0 dynamic linking mechanism in the 1980s, from which the SVR4/ELF mechanism is derived, the offset of the beginning of the GOT from the beginning of the code that uses it is determined at link time ("link" as in "link loader", not "dynamically linking at run time"), so references to the GOT are position-independent.) That appears to be the case, given what section 3.5.3 "Position-Independent Function Prologue" in the x86-64 ABI says:

In the small code model all addresses (including GOT entries) are accessible via the IP-relative addressing provided by the AMD64 architecture. Hence there is no need for an explicit GOT pointer and therefore no function prologue for setting it up is necessary.

"register-to-register spills" "allow programmers (compilers) to spill general-purpose registers to XMM registers, thereby minimizing the number of register spills into memory". As the string "XMM registers" makes it clear, that's x86-64-specific. For instruction sets that have separate GPRs and floating-point registers, and that support moving data from a GPR to an FPR and back again and getting back the exact same bits, that applies there as well. At this point I think most instruction sets have separate GPRs and FPRs are SPARC, but, unless either 1) you can move from register to register without doing integer->float or float->integer conversion, just copying the bits over or 2) the FPRs are wider than the GPRs and the conversions in question can do something such as using the GPR contents as the mantissa, that doesn't help, so maybe that's an x86-64 quirk that doesn't work on some or all other ISAs.

The paper's conclusions about memory pressure in the three ISAs it discusses are based on the number of memory references made by some SPEC2006 integer benchmarks when compiled for those three ISAs, with x86-64 making 8.3% fewer memory references than Alpha. I presume they studied the generated code to conclude that this is "due to lower register pressure".

However, the paper also says, on page 130, that "The high ILP benchmarks bzip2, hmmer, and sjeng prefer execution on Alpha over x86-64, because Alpha offers lower register pressure during phases of high instruction-level parallelism (see Section 3).", so it's not just "x86-64 always has lower register pressure than Alpha".

So the broad claim about CISC vs. RISC and register pressure:

• needs, at minimum, clarification as to what "absolute addressing" is referring to, as the paper appears to use "absolute memory addressing" to mean the same thing as "memory operands in ALU instructions" - maybe "absolute addressing" means "memory operands can consist of an absolute address without involving a register/displacement pair", which is, as far as I know, true in z/Architecture;
• should not speak of those features as being features that "CISC ISAs offer", as some of them are x86-64 only. Guy Harris (talk) 07:19, 22 November 2023 (UTC)

BTW, Thumb with Thumb-2 technology supports all 16 of 32-bit ARM's GPRs, so it's an embedded architecture with 16 GPRs, not just 8; that's a smaller GPR set than the sets of general-purpose RISC ISAs not named "32-bit ARM", but that it may weaken the "While embedded instruction sets [...] suffer from extremely high register pressure because they have small register sets" part of the claim from the article. You may need wider instructions to use the additional 8 GPRs, so there may be a code density penalty for using them, but that's going to need some numbers to clarify. Guy Harris (talk) 07:49, 22 November 2023 (UTC)

Notes

Relation of ISA to architecture

@Digital27: Edit special:Permalink/1185690518 appropriately removed the text also called computer architecture,. I believe that there should still be some mention of an instruction set architecture being a subset of a computer architecture, but I am not sure of how much it should say, how to word it or whether it belongs inline or in a hatnote. Thoughts? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:36, 20 November 2023 (UTC)

I'm fine with your suggestion, you can try to add it as you see fit, a mention somewhere. @Chatul Digital27 (talk) 16:14, 20 November 2023 (UTC)

OK, (at least by IBM) S/360 was the first architecture. There were computers before that, and they had instruction sets, but not so well planned. They built the hardware, and whatever it did, that was the instruction set. So, they can have an instruction set that isn't an architecture. Maybe there could be two different architectures with the same instruction set. That could happen if the I/O architecture was different. But usually when that happens, the instruction set changes to go along. Some architectures have subset instruction sets. Optional instructions. I don't think that is enough to count as different instruction set architecture with the same computer architecture. In the end, I think both terms are a little bit fuzzy, enough to cover differences that I have thought of so far. Gah4 (talk) 17:13, 20 November 2023 (UTC)

Well, on the S/360 you have all of these architectures

1. Instruction set
2. Interrupt
3. I/O
   1. Logical
      1. Common CCW opcodes, sense and status
      2. Interlock and interrupt sequences
      3. Control word formats
   2. Physical
      1. Capacitance limits
      2. Connectors
      3. Distance limits
      4. Pin assignments
      5. Timing

I'm arbitrarily lumping the register sets with the instruction sets, but some might prefer more granularity. Note that these remain invariant with changes in implementation. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:43, 20 November 2023 (UTC)

The computer architecture article says, at the beginning:

In computer science and computer engineering, computer architecture is a description of the structure of a computer system made from component parts. It can sometimes be a high-level description that ignores details of the implementation. At a more detailed level, the description may include the instruction set architecture design, microarchitecture design, logic design, and implementation.

which is broad enough that, for example, the S/3x0 Principles of Operation manuals describe much of the S/3x0 architectures, the manuals describing the channel-to-control-unit connection works describe more of the S/3x0 architectures, and FE and internal documentation for various S/3x0 models describe the architectures of each of those models.

So an instruction set is either part of the architecture of a particular machine, if the machine isn't part of a family of compatible machines where the family has a manual such as the Principles of Operation manual, or part of the architecture of the family, if the family has such a manual. Guy Harris (talk) 19:53, 20 November 2023 (UTC)

I agree that the computer architecture page is fine as is, if someone would like to add something to the ISA

page I think that's fine too. @Guy Harris @Chatul Digital27 (talk) 10:38, 21 November 2023 (UTC)

OK, at least the way IBM sometimes describes it, there is problem state architecture and supervisor state architecture. Problem state only sees non-privileged instructions, and stays more constant. That also gets into the question of which architectures are virtualizable, if you can't tell which state the processor is in using non-privileged instructions. Gah4 (talk) 20:49, 24 November 2023 (UTC)

References