4 ms·

I would love to see an open-source x86 Microcode (or x86 subset Microcode) which would enable a separate open-source RISC CPU (i.e., https://opencores.org/proje

I would love to see an open-source x86 Microcode (or x86 subset Microcode) which would enable a separate open-source RISC CPU (i.e., https://opencores.org/projects?expanded=Processor https://opencores.org/projects?expanded=Processor) to run x86 instructions, or a subset of x86 instructions... Perhaps the path to such an endeavor is simply taking an existing open-source FPGA RISC CPU (RISC-V would be a good choice) -- and then trying to implement a single x86 instruction in open-source Microcode, on it... Success? Well, then let's try another x86 instruction! Eventually we'll have a few! If this or other x86 microcodes are copyrighted and/or patent-protected, what could occur is that a new microcode format (non-copyright or patent infringing) could be defined during this process... Also, an x86 subset FPGA "Soft" CPU -- would never be as fast or as instruction-complete as current Intel or AMD CPU's... In other words, such devices would be for hobbyist and/or educational use only -- they wouldn't compete with current Intel or AMD CPU's...

pabs3 5y ago
What would be the use-case for this? Most open source software is trivially portable across architectures. For the stuff that isn't there are code transformation tools like qemu-user-static.
- peter_d_sherman 5y ago
  Your argument is one of convenience, mine is one of education/understanding... Sure, one could use every computer program in existence without becoming a computer programmer and gain useful function from them, and this would not be wrong in any way -- but there are also those of us who wish to understand things at a very deep level... There are those of us who not only want to understand how computer programs work -- but how ISA's work, how the underlying hardware works, everything down to the substructures, the the adders, the logic gates, the flip-flops, the transistors, everything... And that list includes (but is not limited to!)... x86 microcode... Or more specifically, microcode in general...
  - pabs3 5y ago
    I think it would be better to abandon x86 than to try to understand it :)
- frazbin 5y ago
  Most likely there are microcode bugs being quietly exploited by powerful actors. Documenting/reversing/auditing the code in public makes it more likely white hats will find these bugs and mitigate them.. which takes a little power away from these actors, or at least costs them a bit of money to find a replacement.. and there's always the chance you find a bug worth billions to the agency exploiting it. So while we may never know about it, this is a big deal.
tenebrisalietum 5y ago
You don't really need the microcode to implement the x86 ISA in a meaningful sense unless you are literally trying to copy the exact behavior of a specific x86 CPU down to that microarchitectural layer--which would be odd to need since any program written for x86 + SIMD level has to work on any microarch Intel puts out. You can implement the x86 ISA with existing Intel reference manuals and then testing instructions on a CPU to vet out differences/errata. Microcode doesn't add value to this. Knowing how the instructions work on this level can help optimize code and compilers. This is knowledge Intel likely builds into its ICC compiler that GCC, MSVC and others don't have. Custom microcode could potentially run instructions faster than Intel's, but I really doubt anyone will get there. Another interesting thing is customized instructions. But again portability between microarch's is probably difficult.
- peter_d_sherman 5y ago
  >You don't really need the microcode to implement the x86 ISA in a meaningful sense unless you are literally trying to copy the exact behavior of a specific x86 CPU down to that microarchitectural layer--which would be odd to need since any program written for x86 + SIMD level has to work on any microarch Intel puts out. SIMD is not necessary, nor is most of x86... In fact, I'd be happy to emulate the 386's x86 instruction set in microcode -- and that would be the sum of it... Even all of the 386's instruction set -- probably isn't necessary... You see, what I alluded to earlier was "RISC Core" + microcode. In other words, abstract a layer above a given RISC core with microcode (it could be completely different than Intel's) -- but it could implement x86 instructions. The classic example here is the x86 'REP' instruction prefix. REP when prepended to an x86 instruction -- basically says, "Hey x86 CPU, I want you to implement what basically amounts to a LOOP -- but with a lower-level RISC instruction..." In other words, the looping behavior for those types of instructions -- are implemented at the microcode layer -- they are not implemented by additional physical hardware. Perhaps I'm not thinking abstract enough here... Perhaps the words Intel and x86 confuse things... I suppose what I'd really like to see is an Open-Source RISC CPU (ideally implemented on an FPGA) -- which then implements a microcoded ISA on top of that, and heck, the microcoded ISA doesn't have to be x86 or Intel's -- the microcoded ISA -- could be a completely separate assembly language, but the thing is, it's Open-Source (unlike Intel/AMD's microcode to date), and created by an abstraction layer on top of the FPGA RISC (which should also be Open-Source)...
spijdar 5y ago
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 could be meaningfully re-used to drive other CPU cores, unless you also reverse engineered Intel hardware :-) I don't think many RISC processors even use microcode in the first place. On most RISC chips I know of, most instructions are cracked/decoded/ran in one cycle, with only very complex instructions needing to be run across multiple CPU cycles. Most RISC-V implementations don't use microcode at all, AFAIK. If you're just saying we should make an open source x86-compatible CPU core that can be synthesized to FPGA, there are actually several projects that do so, including several on OpenCores, like: https://opencores.org/projects/ao486 https://opencores.org/projects/ao486 https://opencores.org/projects/next186 https://opencores.org/projects/next186 https://opencores.org/projects/v586 https://opencores.org/projects/v586
- 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?

pabs3 5y ago

What would be the use-case for this? Most open source software is trivially portable across architectures. For the stuff that isn't there are code transformation tools like qemu-user-static.

peter_d_sherman 5y ago
Your argument is one of convenience, mine is one of education/understanding... Sure, one could use every computer program in existence without becoming a computer programmer and gain useful function from them, and this would not be wrong in any way -- but there are also those of us who wish to understand things at a very deep level... There are those of us who not only want to understand how computer programs work -- but how ISA's work, how the underlying hardware works, everything down to the substructures, the the adders, the logic gates, the flip-flops, the transistors, everything... And that list includes (but is not limited to!)... x86 microcode... Or more specifically, microcode in general...
- pabs3 5y ago
  I think it would be better to abandon x86 than to try to understand it :)
frazbin 5y ago
Most likely there are microcode bugs being quietly exploited by powerful actors. Documenting/reversing/auditing the code in public makes it more likely white hats will find these bugs and mitigate them.. which takes a little power away from these actors, or at least costs them a bit of money to find a replacement.. and there's always the chance you find a bug worth billions to the agency exploiting it. So while we may never know about it, this is a big deal.

tenebrisalietum 5y ago

You don't really need the microcode to implement the x86 ISA in a meaningful sense unless you are literally trying to copy the exact behavior of a specific x86 CPU down to that microarchitectural layer--which would be odd to need since any program written for x86 + SIMD level has to work on any microarch Intel puts out. You can implement the x86 ISA with existing Intel reference manuals and then testing instructions on a CPU to vet out differences/errata. Microcode doesn't add value to this. Knowing how the instructions work on this level can help optimize code and compilers. This is knowledge Intel likely builds into its ICC compiler that GCC, MSVC and others don't have. Custom microcode could potentially run instructions faster than Intel's, but I really doubt anyone will get there. Another interesting thing is customized instructions. But again portability between microarch's is probably difficult.

peter_d_sherman 5y ago
>You don't really need the microcode to implement the x86 ISA in a meaningful sense unless you are literally trying to copy the exact behavior of a specific x86 CPU down to that microarchitectural layer--which would be odd to need since any program written for x86 + SIMD level has to work on any microarch Intel puts out. SIMD is not necessary, nor is most of x86... In fact, I'd be happy to emulate the 386's x86 instruction set in microcode -- and that would be the sum of it... Even all of the 386's instruction set -- probably isn't necessary... You see, what I alluded to earlier was "RISC Core" + microcode. In other words, abstract a layer above a given RISC core with microcode (it could be completely different than Intel's) -- but it could implement x86 instructions. The classic example here is the x86 'REP' instruction prefix. REP when prepended to an x86 instruction -- basically says, "Hey x86 CPU, I want you to implement what basically amounts to a LOOP -- but with a lower-level RISC instruction..." In other words, the looping behavior for those types of instructions -- are implemented at the microcode layer -- they are not implemented by additional physical hardware. Perhaps I'm not thinking abstract enough here... Perhaps the words Intel and x86 confuse things... I suppose what I'd really like to see is an Open-Source RISC CPU (ideally implemented on an FPGA) -- which then implements a microcoded ISA on top of that, and heck, the microcoded ISA doesn't have to be x86 or Intel's -- the microcoded ISA -- could be a completely separate assembly language, but the thing is, it's Open-Source (unlike Intel/AMD's microcode to date), and created by an abstraction layer on top of the FPGA RISC (which should also be Open-Source)...

spijdar 5y ago

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 could be meaningfully re-used to drive other CPU cores, unless you also reverse engineered Intel hardware :-) I don't think many RISC processors even use microcode in the first place. On most RISC chips I know of, most instructions are cracked/decoded/ran in one cycle, with only very complex instructions needing to be run across multiple CPU cycles. Most RISC-V implementations don't use microcode at all, AFAIK. If you're just saying we should make an open source x86-compatible CPU core that can be synthesized to FPGA, there are actually several projects that do so, including several on OpenCores, like: https://opencores.org/projects/ao486 https://opencores.org/projects/ao486 https://opencores.org/projects/next186 https://opencores.org/projects/next186 https://opencores.org/projects/v586 https://opencores.org/projects/v586

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?