|This is the talk page for discussing improvements to the Microcode article.
This is not a forum for general discussion of the article's subject.
|WikiProject Computing / Software||(Rated C-class, Mid-importance)|
- 1 Changed "lowest" to "lower"
- 2 Critique of the article
- 3 Microcode redirect
- 4 PDP-8 "microinstructions"
- 5 Praise
- 6 Grave omission!?
- 7 Work in progress
- 8 Modern x86 processors
- 9 Move to Microcode
- 10 Intel Core Microarchitecture
- 11 some CPUs don't use microcode
- 12 writable microcode
- 13 Feature article
- 14 Microinstruction width
- 15 Would references be helpful?
- 16 "Microcode vs. VLIW/RISC"?
- 17 Microcode that doesn't implement instruction sets?
- 18 History
- 19 68K
- 20 Decoding of horizontal micro-orders
Changed "lowest" to "lower"
...because wrt one machine I know of, the Northern Telecom SL/1, microcode was supported by a deeper level of code called nanocode.
- Don't let the naming mislead you! Nanocode is just a special case of microcode - microcode in two levels - a similar approach was used in the 68000, for example. 220.127.116.11 (talk) 07:18, 24 September 2009 (UTC)
Critique of the article
I am a computer engineer, as was kind of confused also. This is really not a place for technical info I guess. —The preceding unsigned comment was added by 18.104.22.168 (talk • contribs) 13:37, 16 June 2004 (UTC)
- if you two have sufficient technical know-how to criticize the article, why don't you amend it so that it is accurate? after all, is that not the point of a wikipedia?—The preceding unsigned comment was added by 22.214.171.124 (talk • contribs) 03:33, 17 November 2004 (UTC)
I came here to find out what microcode was. Microcode redirects to this article, which present WAY more info than I can follow...oerhaps someone who knows what they are can add an additional article on microcode specifically, so I can learn what it is?—The preceding unsigned comment was added by 126.96.36.199 (talk • contribs) 07:04, 5 September 2005 (UTC)
I disagree with the use of the PDP-8 as an example of vertical microcode. The use of the term "microinstruction" on the PDP-8 has an almost entirely different meaning that conventional microprogramming, but it is more akin to horizontal microprogramming than vertical, because it uses bitfields to control independent (though related) operations.
A better example of vertical vs. horizontal would be the HP 2100 vs. the IBM 360/65. The former has a very narrow (24-bit) microword, and is very vertical, while the latter has a very wide word (105 bits, IIRC) that has almost no encoding - most of the fields directly control individual hardware operations.
The use of the term "microinstruction" on the PDP-8 should perhaps be explained in its own section, with an explanation that the PDP-8 is not microcoded in the normal sense, but is hardwired and has an ISA that includes the "operate" instruction with fields for various operations. --Brouhaha 06:06, 10 September 2005 (UTC)
- I understood that section to mean something different. I think it was trying to use the PDP-8 assembly language as a rough example of what "vertical microcode" is like. (I don't necessarily agree that PDP-8 assembly language is the best example).
- On the other hand, you're correct that what the PDP-8 called "microinstructions" has very little to do with what we're talking about here and we might want to explicitly disclaim much relationship.
- Atlant 23:34, 10 September 2005 (UTC)
Thanks this is a really good summery about microprogramming....if someone does not understand this and claims to be a computer engineer i recommend to switch your career.—The preceding unsigned comment was added by 188.8.131.52 (talk • contribs) 08:46, 31 October 2005 (UTC)
- If someone types in the above and can't even spell 'summary' or 'I' then I recommend you switch off your computer and immediately stop wasting the planet's ecological system.
- Note the above user was ostensibly accessing Wiki from the University of Toronto. Canada must therefore go back to the drawing boards if their students still can't spell or type. Sorry, Canada.] —The preceding unsigned comment was added by 184.108.40.206 (talk • contribs) .
- Atlant 22:30, 25 June 2006 (UTC)
Wow, I can't understand it, and I have written in machine language, IBM 360/370 assembler language, Fortran, Basic, SAS, and 8051 machine (microprocessor) language. How about a good example of microcode /firmware? I couldn't think of one, except maybe "move character long" (moving megs of data instead of much less).
I was quite simply flabbergasted when I noticed that this article does not at all mention the reprogrammability (flexibility, upgradability) reason for using microprogramming vs hardwiring. Correct me if I'm wrong, but isn't this reason as important as the emulation issue? --Wernher 23:15, 21 January 2006 (UTC)
- But the article does mention this! See:
- Microprogramming also reduced the cost of field changes to correct defects (bugs) in the processor; a bug could often be fixed by replacing a portion of the microprogram rather than by changes being made to hardware logic and wiring.
- If you feel it needs more stress, this is Wikipedia so you know what to do: be bold!
- Atlant 01:33, 22 January 2006 (UTC)
Work in progress
I stumbled across this article. As the above comments indicate, it definitely needs some work. I have some experience in this area, so will contribute what I can. Post any issues or questions here. Joema 02:07, 4 March 2006 (UTC)
- The change to the VAX section is wrong. The first VAX, the VAX-11/780, did not use AMD 2901 bit slice components. I don't think any VAX did use those for the main CPU other than possibly the low-end 11/730 (and the electrically identical 11/725). --Brouhaha 06:18, 4 March 2006 (UTC)
- Revised VLIW/RISC section. Added some items and removed "RISC as vertical microcode" sentence. This seems like a stretched comparison, not sure it's sufficiently close to warrant using. Discuss if any questions. Joema 18:45, 4 March 2006 (UTC)
- Thought about it and restored RISC/vertical microcode comparison. Joema 19:01, 4 March 2006 (UTC)
- Brouhaha, you're correct -- only Nebula/Low-Cost-Nebula (11/730, 11/725) used the AMD bit-slices. (We also used them in the PDP-11/34 and /44 Floating-Point Processors, but that's not at issue here.)
- Atlant 17:51, 29 June 2006 (UTC)
Modern x86 processors
How does microprogram/microcode, specifically the VLIW/RISC section, compare to modern x86 CPU's? Like modern Pentium processors exposing a CISC instruction set but internally resembling more of a RISC processor? Fuzzbox, 29 June 2006
Intel Core Microarchitecture
Needs more info on intel's recent advances in microarchitecture
- Do those advances in microarchitecture have anything to do with microcode? (The fact that both words include the prefix "micro" does not indicate that microcode is involved in all aspects of microarchitecture.) If not, perhaps this question should be asked on the Intel Core Microarchitecture talk page, not the talk page for the microcode page. Guy Harris 06:35, 28 August 2006 (UTC)
some CPUs don't use microcode
The first few paragraphs seem to imply that *all* CPUs use microcode.
Towards the end, the "Microcode versus VLIW and RISC" section says that VLIW and RISC CPUs do not use microcode.
Then it claims that more recent "Modern implementations of CISC instruction sets" use microcode for only *some* instructions. (Is this a round-about method of talking about Intel Pentium processors, or is there some other "modern ... CISC"?)
I suspect this is incorrect.
My understanding is that, the instruction decoder on modern Pentium processors breaks down x86 instructions into one or more internal micro-ops, so it does have some similarities to the microcode store. But the information inside that decoder is technically not microcode, because the decoder is technically not a control store, because its output lines to not directly control the various parts of the Pentium CPU. Instead, the decoder output lines feed into the micro-op buffer, and as many micro-ops as possible (which varies cycle-by-cycle) are munched on each cycle (as selected by the superscalar dispatch unit).
Is it really true that some processors use microcode for some but not all instructions? --220.127.116.11 05:47, 15 October 2006 (UTC)
- I've rewritten the first few paragraphs a bit in an attempt not to imply that all CPUs use microcode.
- "Modern implementations of CISC instruction sets" is a way of talking about modern implementations of CISC instruction sets, including but not limited to recent Pentium processors; it also includes modern Intel x86 processors that don't have Pentium in their name, modern AMD x86 processors, and, I think, modern descendants of the System/360 processors (System/390 and z/Architecture).
- In the case of S/390 and z/Architecture processors, most instructions are executed directly by hardware; others trap to what IBM calls "millicode", which consists of a combination of S/390 or z/Architecture instructions and special instructions executable only in a special "millicode" mode. See, for example, C. F. Webb and J. S. Liptay (1997). "A high-frequency custom CMOS S/390 microprocessor". IBM Journal of Research and Development 41 (4/5): 463–474. doi:10.1147/rd.414.0463. ISSN 0018-8646. Retrieved 2006-10-16. That could be thought of as similar to PALcode on DEC Alpha processors.
- In the case of P6 and later x86 processors from Intel, I have the impression that some instructions are directly translated to uops by the hardware, and other instructions cause a sequence of uops to be fetched from on-chip store; those sequences of uops could be thought of as microcode. They might not be horizontal microcode that directly controls gates in the processor, but not all microcode is horizontal.
- In the case of the Nx586 and the AMD K6 and later x86 processors from AMD, I have the impression that they work similarly to the P6 and later Intel processors; at least in the Nx586 and K6, the internal operations are called "RISC86", suggesting that they're a RISC-like instruction set. They might also have some RISC86 code in on-chip store, functioning as a microcode equivalent for some of the more complex instructions. Guy Harris 08:26, 16 October 2006 (UTC)
I was under the impression that all Intel and AMD processors, if they had microcode at all, had only read-only microcode. So once the chip was made, it is impossible to "update" the microcode.
Do Intel processors have a writable microcode after all?
--18.104.22.168 04:36, 13 July 2007 (UTC)
- There are Intel x86 processors that have writable microcode - the Intel P6 processors, for example, have it. Guy Harris 05:51, 13 July 2007 (UTC)
- Which parts do you like the best? It would be interesting to hear.
The wording the microinstruction is often as wide as 50 or more bits is a bit awkward; both structurally and because the article later mentions a width of 108. I'd suggest the microinstruction is often as wide as 108 bits or the microinstruction is often wider than 50 bits.
The microinstruction width on the 360/85, 370/165 and 370/168 was only 108 bits if there was no emulator feature installed; with a 7070, 7080 or 7090 emulator feature the width was larger. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:45, 13 July 2010 (UTC)
Would references be helpful?
Would it be helpful to provide technical references for the micro instruction formats on some processors, or would that be TMI? I can probably track down the manual names and numbers for some of
*IBM 360/40 *IBM 360/50 *IBM 360/65 *IBM 370/145 *IBM 370/155 *IBM 370/165 *RCA 601 Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:51, 13 July 2010 (UTC)
"Microcode vs. VLIW/RISC"?
"Microcode" and "RISC" aren't, strictly speaking, complete opposites. CISC and RISC are instruction set design philosophies; microcode and random logic/state machines are implementation techniques. CISC processors have been implemented without microcode (IBM System/360 Model 75, GE-600 series and the Honeywell 6000 series) and largely in hardware with only some instructions implemented in microcode (later x86 processors) or in "millicode" (later IBM System/390 processors, z/Architecture processors). RISC processors are largely implemented without microcode (please provide explicit references for claims to the contrary). Guy Harris (talk) 08:14, 25 August 2010 (UTC)
Microcode that doesn't implement instruction sets?
The article starts with
- Microcode is a layer of hardware-level instructions or data structures involved in the implementation of higher level machine code instructions in many computers and other processors; it resides in special high-speed memory and translates machine instructions into sequences of detailed circuit-level operations.
which speaks of microcode as a technique for implementing an instruction set, rather than, for example, directly implementing the algorithm(s) the machine is ultimately intended to perform.
One could argue that the term "microcode" has also been used for code that directly implemented those algorithms, e.g. the microcode in an IBM 3880 disk controller probably didn't implement an instruction set in which the controller's algorithms were encoded, the microcode probably directly implemented those algorithms.
In addition, the article says
- Microcoding remains popular in application-specific processors such as network processors.
but I suspect the microcode in the network processors doesn't implement an instruction set in which the network algorithms are encoded, they probably directly implement the algorithms.
I'm not sure what would distinguish between a microinstruction set and a specialized (non-micro-)instruction set in those cases - Harvard architecture so that the code and data are separate? More VLIW-style instructions, perhaps with fields of the instruction having a more directly connection to hardware functions, along the lines of horizontal microcode? Guy Harris (talk) 00:24, 4 August 2012 (UTC)
- Indeed. Properly speaking microcode is used to impliment an instruction set, but from the 1960's IBM referred to VLIW code used for other purposes as microcode. Further, on the low end IBM System/360 and S/370 machines, IBM used the same hardware instruction set to simulate the architect instructions and to implement the I/O channels.
- To add to the confusion, other terms have been used for code and instruction sets used to simulate another instruction set, e.g., logand and logram on the TRW-130; see bitsavers for manuals. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:38, 7 August 2012 (UTC)
@Dsimic: Aren't the History and Justification sections basically two history sections, which need to be merged? The Justification section is basically history. I mean the history of development of most things, is that of its justification. It's not like it was conceived out of sabotage or stupidity. ;) It seems like they should be merged in timeline order. — Smuckola (Email) (Talk) 17:47, 22 January 2015 (UTC)
- Hello! That's a good point, they share a lot while being a bit too wordy. IMHO, it might be the best to rework (and compact) "Overview", "Justification" and "History" sections into resulting "Overview" and "History" sections, where the content from "Justification" would be split between both sections. I might take a shot at it later today, and we could move on from there – if you agree. — Dsimic (talk | contribs) 18:04, 22 January 2015 (UTC)
- @Dsimic: I'm way out of my depth on the direct subject matter. I'm more in the area of just copy editing and formatting. I can't imagine who on earth wrote all this intense detail, with no citations. This isn't exactly personal memoirs. I was gritting my teeth through all the typical nostalgic faux-past tense, while reading all these statements of fact and nodding my head, "Yup yup yup, sounds goooood. Sounds like I sure am glad we have microcode, then. p.s. Mainframes sound HARD. Thanks for saving the world, IBM!" — Smuckola (Email) (Talk) 18:59, 22 January 2015 (UTC)
- Well, the article is very well written but quite wordy in some sections; perhaps the people who wrote it used some references but missed to note them in the article. I'll do the above described compaction later today, it should be rather good. At the same time, cleanups you've performed are just fine and according to MOS:COMPNOW. — Dsimic (talk | contribs) 19:10, 22 January 2015 (UTC)
- @Dsimic: Oh cool, MOS:COMPNOW will help with the essay I'm writing about tense. Maybe it would be worth scanning the article's history or using wikiblame, and contacting the major contributors who are already familiar with the sources and can cite them. It seems like somebody probably wrote well-formatted and well-thought-out prose like this in educated swaths. Or, that's wishful thinking. — Smuckola (Email) (Talk) 00:57, 24 January 2015 (UTC)
- Here are a few nice papers that we can use as references for a large part of the article:
- I'll see to incorporate them while compacting above mentioned sections. — Dsimic (talk | contribs) 01:28, 24 January 2015 (UTC)
- @Dsimic: No, I said "disregard", not "discard". The existing content is presumably based upon the references which are already present to be harvested for inline citations. There may not be any need for new references. If there were, they'd be RSes, not the sources you presented. — Smuckola (Email) (Talk) 19:33, 24 January 2015 (UTC)
I'm surprised the 68K is not included in the discussion of horizontal and vertical microcode, as it uses a double layer microcode to map the possible control lines into a smaller index number into the much smaller number of unique control line patterns. 22.214.171.124 (talk) 20:29, 8 March 2015 (UTC)
Decoding of horizontal micro-orders
I know of no IBM processor with horizontal microcode in which the micro-orders are not decoded. Typically Read Only Storage (ROS) was expensive, and it was cost effective to have a minimal amount of encoding of, e.g., register selections, ALU function. Of course, vertical microcode has more extensive encoding. Note that the definition in practice does not match that coined by Wilkes. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:50, 28 May 2015 (UTC)