Talk:Instruction set architecture

message: 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)
replies: text: 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)
replies: text:  Fixed. --Wtshymanski (talk) 18:49, 8 March 2011 (UTC)
thread_title: Link to this page from this page for "instruction"

message: 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)
thread_title:  SWEET16 

message: 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)
replies: text: 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)
thread_title:  Riscs Are usually THREE operand 

message: 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)
replies: text: 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)
thread_title:  Incorrect classification of S/360 and S/370 implementations 

message: 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)
replies: text: 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)
thread_title:  Code density 

message: 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 Microcode with 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)
replies: text: 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)

text: 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)
replies: text:  Agree.  Microcode, unless user-microcodability is part of the architecture, is an implementation detail. Guy Harris (talk) 20:41, 18 January 2013 (UTC)

text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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. — Preceding unsigned comment added by Guy Harris (talk • contribs) 20:37, 23 January 2013 (UTC)
thread_title:  Separate data and instruction memories 

message: 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)
thread_title:  What is an instruction? Section or separate article needed 

message: 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)
thread_title:  Oocodes for 'software interrupt' - Design 

message: 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)
thread_title:  commentary 

message: Couldn't we just write that instead of the current "… is an abstract model of a computer". User:ScotXWt@lk 19:10, 14 July 2017 (UTC)
replies: text: 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)
thread_title:  … is a set of commands/micro-operations 

message: There is a  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)
replies: text: 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)
thread_title:  DSP citation 

message: The second paragraph of the lead says
To what does "the hardware support for managing main memory" refer? Given that, right afterwards, the paragraph speaks of "fundamental features" such as "memory consistency, addressing modes, and virtual memory", presumably it does not refer to any of those. Given that the physical interface between the CPU and main memory is a characteristic of a particular implementation of an ISA, not of the ISA itself, it presumably also doesn't refer to that.
Perhaps if some aspects of a CPU cache are visible at the ISA level, such as cache prefetch and flushing instructions (which might behave differently on different implementations, and might even be no-ops on some implementations), or instructions that return information about that cache, being present in the ISA, that might be what it refers to.
I've added a  tag to "hardware support for managing main memory". Guy Harris (talk) 05:25, 24 April 2024 (UTC)
thread_title:  What does "Hardware support for managing main memory" refer to?