3 ms·

A little confused by what exactly you're proposing. Microcode is closely tied to a specific hardware implementation, there's no way the existing Intel microcode

• sidpatil 5y ago
  Here's [1] an example of a CPU with the same functionality that the parent poster is interested in: the ISA being implemented in what amounts to microcode. [1] https://en.m.wikipedia.org/wiki/Transmeta_Crusoe https://en.m.wikipedia.org/wiki/Transmeta_Crusoe
• peter_d_sherman 5y ago
  OK, well, to begin this discussion then, we either agree that Intel/AMD CPU's (and other x86 CPU's) -- are basically RISC CPU cores with microcoded instructions above the RISC core layer -- or we don't... If we don't agree -- then I can submit link after link, URL after URL, text excerpt after text excerpt -- to prove to you that this is the case with Intel/AMD CPU's (and pretty much most other commercial CPU's that use large instruction sets) since the 1980's. Anytime a CPU is microcoded in any way -- that's a good indication that there's a RISC core in there -- at a level below the microcode dispatch mechanism... Why? Because there are so many reasons to architect a CPU like that! It makes a huge amount of sense! Why put tons of extra gates on a CPU to implement a super-large instruction set, many of which won't be used in most applications -- when the CPU design can be simplified and streamlined by use of a RISC core -- and microcode on top of that layer? https://stackoverflow.com/questions/5806589/why-does-intel-hide-internal-risc-core-in-their-processors https://stackoverflow.com/questions/5806589/why-does-intel-h... But you see, while most of the x86 Instruction Set is documented -- (I say most, because we always seem to be discovering new x86 instructions!) -- most of the x86 microcode -- the code which implements those x86 instructions -- has not historically been documented by Intel... In other words, it's a gray area, black box, a "dragon"... If someone wants to understand their computer, from the smallest transistor to the largest OS/Compiler/Application -- then they'd certainly seek an understanding of the microcode as well. Historically Intel/AMD have not been forthcoming, not transparent, in their disclosure of Microcode, thus trying to gain an understanding into this aspect of computational hardware -- is left to independent researchers, such as the Microcode Research Team, above. That's not good -- because in an ideal world, it would be transparent -- as transparent as any other piece of Open Source software... Thus, my proposal to remedy the problem via an Open-Source equivalent. Have I answered your question?
  • gpderetta 5y ago
    Microarchitecturally Intel CPUs are not RISC. Most instructions translate to a single uop, at least in the fused domain, including read-modify and modify-write, which is antithetic to RISC. Also ups are not fixed size. Also microcoding, which is distinct from uop splitting, predates RISC by decades.
    • adrian_b 5y ago
      When it appeared, RISC did not claim to be something distinct from (vertical) microcoding. Because at that time it became feasible to have fast cache memories for instructions, the speed of executing a sequence of instructions from the instruction cache became the same as the speed of executing the equivalent sequence of (vertical) microinstructions from a microcode memory. Because microcoding complex instructions could no longer provide any speed advantage, the RISC proponents advocated the removal of the complex instruction decoder and of the microcode memory and the use of the space thus freed for faster execution units and larger cache memories. So RISC CPUs were conceived as just (vertically) microcoded CPUs which exposed the micro-operation ISA directly to the programmer, instead if using it for implementing a complex ISA to be used by the programmer. A few years later, the VLIW CPUs appeared as an alternative for RISC, which were conceived as CPUs with a horizontal micro-operation ISA exposed directly to the programmer.
  • spijdar 5y ago
    I think I understand what you mean now, although it's different from my first interpretation. I agree an open source microcode for Intel/AMD would be a very good thing, although I think if it was based on actual Intel microcode, it would need to run on an Intel or AMD processor, or require a lot of work to reverse engineer a modern Intel microcode sequencer/front-end. If the goal is to make an efficient, microcoded CPU that implements the x86 ISA, I can see where you'd benefit from re-using an existing core, although I think you'd need to make many modifications to the hardware to get there. If using a modern Intel chip as an example, say Skylake [0], a RISC chip could be turned into the "execution engine", but you'd still need to design a new front-end to fetch/decode/sequence the microcoded instructions to the RISC backend. I'm surprised there's not more work to do something like that. Most FPGA re-implementations of CISC processors I know of don't seem to implement a core like this, I guess there are other bottlenecks that make it a pointless optimization unless you plan to make an ASIC out of it eventually. [0] https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(client) https://en.wikichip.org/wiki/intel/microarchitectures/skylak...