|WikiProject Computing||(Rated C-class, Mid-importance)|
I have made major revisions to this stub. I added information about microarchitecture, the history, different types, and implementations. Please let me know if you have any comments or concerns. Thank you
I think this article is beautifully written, and as a chemistry student with a life long interest in computers, I found this very easy to understand and now I have a much greater understanding of how the CPU works. Grammar and such can be fixed, but I think the content style is just perfect. If someone plans to add in more technical information and / or mathematical derivations, please preserve this content. - Bryan, UT
- 1 Very confused article
- 2 Merge with Computer organization ?
- 3 Process of Design
- 4 Memory
- 5 Ick.
- 6 Duplicate Info
- 7 Microarchitecture is controlled by State Machine or Microcode; article should be labeled prejudiced due to RISC bias
- 8 RE: prejudice and ... Archaic definition of Microarchitecture
- 9 should we make a split
Very confused article
The definition of uarch used in this article is very confused. For microprocessors, uArch design is the system-level design which is implementation specific and does not affect Instruction set behavior. For example having 2 integer ALUs vs 1, having that ALU be 4 pipeline stages long as opposed to 6. So the first paragraph IS correct.
The second paragraph uses the term "physical". That's a dangerous term to use. For microprocessors, "physical" design means layout or mask design. The term "Microarchitecture design" is solely used for system design that's done before logic design, never for circuit design.
The History section is incorrect. It seems to confuse microarchitecture with miniaturization. As used in Computer architecture, the "micro" in microarchitecture is a mis-nomer. It came from the days of micro-code and microprogramming - the design of a CPU below the level of the "macro" instruction, eg. the user-visible instruction set.
The Component section isn't saying anything relevant. Yes, these are components used in microprocessors, but that doesn't directly explain what microarchitecture is.
The Types section is also 100% incorrect. As previously stated, uArch is NOT instruction set architecture. Just the opposite. It's closer to types of pipelines , eg. 5-stage pipeline vs 15-stage pipeline.
ps. For edits on a talk page, you ought to leave your signature (4 tildes). Like this. Dyl 06:28, 22 February 2007 (UTC)
- I removed the incorrect sections and rewrote alot of what remained. Dyl 16:24, 23 February 2007 (UTC)
- This article obviously needs to start citing specific passages out of the main academic textbooks on the subject, which are easily ranked by importance using major universities and such, and papers, which are not as easily ranked for importance, reliability, and notability. Int21h (talk) 18:16, 14 May 2010 (UTC)
Merge with Computer organization ?
That other article has a nice description paragraph of this activity, but not much else. This article has a more complete listing of concepts that are used in this activity. My opinion is the 2 articles ought to be merged. Also, nobody in the industry uses the term computer organization, rather it's architecture or more correctly microarchitecture. Dyl 17:03, 25 February 2007 (UTC)
I agree that the too topics should be merged. Computer organization could be redirected to microarchitecture. Although I have no industry experience, I know these two topics were introduced as one in the classroom. --Timmh 20:52, 6 March 2007 (UTC)
Nobody in the industry uses computer organisation ? But everydody who wrote books about this subjet name them as computer architecture and organization (Murdocca & Heuring), Computer Architecture (Hennessy & Patterson), Computer Organisation & Design (Patterson & Hennessy), and a lot of others found easily in Google. So I think the main title should reflect the references, not the word used by people. Moreover, (micro)architecture is only a part of the computer organization and/or design. Majorkell (talk) 14:39, 11 February 2008 (UTC)
I learned this subject as computer organization, along with the ISA, as different subjects of computer architecture. As I learned it, out of Computer Organisation & Design by Patterson & Hennessy, the materials covered in this article (microarchitecture) are what I learned under the term computer organization. Int21h (talk) 18:12, 14 May 2010 (UTC)
Process of Design
In my experience with microarchitecture (undergraduate processor architecture class) the design was created using a hardware description language such as Varilog or VHDL. My question to those in industry, does this fit with this article? I believe that the article would benefit from a section describing the use of a HDL. Thoughts? --Timmh 21:00, 6 March 2007 (UTC)
- Any digital design with over a dozen logic gates is done with a HDL like Verilog or VHDL, meaning all projects in industry. That fact has nothing to do with microarchitecture. If you mention HDL, why not mention boolean logic or semiconductor physics? HDL is an implementation tool/strategy, which again, is not microarchitecture. Dyl 13:54, 7 March 2007 (UTC)
As the architecture use constraints coming from a lot of sources, I think all should be mentionned if possible. Physics contraints clock, routing, size, ... HDL describs logic and path and enforce using particular technics, ... memory, peripherals, ... all are used to teach this subject and even industrials should agree that subjets should at least be mentionned in this page because they are particularly determining for the architecture. Majorkell (talk) 14:59, 11 February 2008 (UTC)
It seems that something should be said about how memory relates to microarchitecture. It is my understanding that the memory subsystem is usually contained in the microarchitecture. In other microarchitectures memory controllers are part of the microarchitecture. I believe a section on memory would benefit the article. --Timmh 04:14, 27 March 2007 (UTC)
Trying to fix. This is a bit of a mess without a single voice. I'm killing large swaths of verbage at the moment, please let me know if I killed something I shouldn't have. We could _really_ use some figures as examples of data path, control path, etc. Anyone got anything in the public domain that would work? Hobit (talk) 20:31, 21 May 2009 (UTC)
- They're not necessarily the same thing. With speculative execution, you can start down both paths, so you don't need to predict. Or you can start down the predicted path, and back out if it was wrong. With prediction, mostly you just prefetch and get ready to take predicted path; if you do more than that, it's speculative execution. But it's true that the sections as written are largely overlapping and don't make this distinction clear. Work on it from a source, and it will come out better. Some of these would be good. Dicklyon (talk) 05:59, 9 September 2009 (UTC)
Microarchitecture is controlled by State Machine or Microcode; article should be labeled prejudiced due to RISC bias
1.) From an external point of view of a Microprocessor we see the Instruction Decoder. The Microinstructions generated by the Instruction Decoder act directly on the Micromachine Microarchitecture. The Micromachine is controlled by either digital logic gates like a State Machine (CPUs like CDP1802, 8X300, and early RISC CPUs e.g. IM6100/PDP8) or by Microcode (6502, MC680x0, i8080 and newer).
2.) The IBM (PC,XT,AT)/370 mainframe emulators used Motorola MC68000 with internal masked microcode that caused the Instruction Decoder to execute IBM System/370 instructions.
3.) Intel CPUs allow BIOS to update Microcode on boot, or even update Microcode in Windows, ostensibly to fix discovered flaws.
4.) RISC vs CISC is an Instruction Set issue. RISC stands for Reduced Instruction Set Computing in fact. The Architecture of the underlying Micromachine is unlikely to bear directly upon the choice of Instruction Set. Instruction Sets that have survived are those that are productive for programmers. True RISC machines have difficulty with subroutines in ROM. True RISC does not include Virtual Memory Management instructions, a requirement for multitasking rather than 1970's punched card batch jobs.
5.) Hardware level or Micromachine level functionality such as cache configuration, pipeline management, and register renaming are irrelevant to RISC or CISC but are part of the Micromachine Architecture. Hardware tricks to make up for RISC lack of usability, such as registers that always return a constant (ARM) and fast (internal) page zero RAM(TI-990). We used TMS9995 for embedded control because of the register file in internal fast memory; although this like SPARC is RISC instruction set acting load-store, accesses were hidden by hardware architecture, were actually memory to memory which is decidedly non-RISC.
6.) SPARC was not fast because it was RISC, it was fast due to hardware. The limitation of its hardware method caused SUN to abandon SPARC architecture in favor of x86:
- SPARC usually contains about 128 or 144 registers, (memory-data designs typically had 16 or less). At each time 32 registers are available - 8 are global, the rest are allocated in a 'window' from a stack of registers. The window is moved 16 registers down the stack during a function call, so that the upper and lower 8 registers are shared between functions, to pass and return values, and 8 are local. The window is moved up on return, so registers are loaded or saved only at the top or bottom of the register stack. This allows functions to be called in as little as 1 cycle. Like most RISC processors, global register zero is wired to zero to simplify instructions, and SPARC is pipelined for performance (a new instruction can start execution before a previous one has finished), but not as deeply as others - like the MIPS CPUs, it has branch delay slots. Also like previous processors, a dedicated CCR holds comparison results.
- SPARC is 'scalable' mainly because the register stack can be expanded (up to 512, or 32 windows), to reduce loads and saves between functions, or scaled down to reduce interrupt or context switch time, when the entire register set has to be saved. Function calls are usually much more frequent than interrupts, so the large register set is usually a plus, but compilers now can usually produce code which uses a fixed register set as efficiently as a windowed register set across function calls.
7.)When Apple switched from 68030/68040 @33MHz to PowerPC architecture @66 MHz program execution was actually SLOWER WITH RISC due to RISC requirement of more instructions for the same task and use of same speed memory for both systems.
8.) TMS9900 used 4 phase clock, digital logic, and state machine instruction decode and timing. Complex digital logic is prone to transient glitches (e.g. race conditions) but simpler implementations take up less silicon. Chip designers "take the easy way out" by using Microcode. Later TMS99000 versions are microcoded.
from the Data General NOVA RISC minicomputer architecture to its successor microBlaze (from Fairchild 9440 microFlame) (version 5) http://www.xilinx.com/support/documentation/sw_manuals/mb_ref_guide.pdf Shjacks45 (talk) 13:24, 4 May 2010 (UTC)
RE: prejudice and ... Archaic definition of Microarchitecture
The reference(Computer Science in the 60s?) in the article to the architecture to be the physical boxes that made up the IBM System/360 and the structure of the parts inside the boxes as microarchitecture seems at odds with the current definition that the architecture of the CPU is its programming model and the "Microarchitecture" being its internal structure, or "Ghost in the Machine".
should we make a split
should we make a split for the term used in this article (Microarchitecture) to clear up some confusion? one of my ideas was to make another article names Microarchitecture (CPU) and Architecture (CPU) to clear up some confusion with intel and amds format, and then also implementing those into the CPU infobox template. Matthew Smith (talk) 13:22, 6 September 2012 (UTC)