Talk:Instruction set architecture

Intro

I have included a simple definition for mortals.

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)

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)

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.