Hacker News Reader

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/next186

https://opencores.org/projects/v586

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

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-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?

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/skylak...

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.

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.

The fact that CPUs internally have microcode doesn't mean there's a different RISC CPU lurking underneath that you could just take the lid off of. In particular, the instruction decoder, which is what you're proposing to change, is not implemented in microcode; that would just be way too slow.

An x86 CPU is made for executing x86 instructions.

That would depend on how and what you can feed it? Say if you'd got a backend for something like LLVM, which emits the µOps directly, thereby circumventing the instruction decoder, if technically/architecturally possible at all. Instead of going through the instruction decoder.

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.

>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)...

Article is about reverse engineering Intel's microcode.

> abstract a layer above a given RISC core with microcode.

> 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

Microcode's a very CPU-specific thing - as in specific to how the CPU is implemented internally, which can differ between vendor, microarch, stepping, or other things.

Different RISC CPUs may have different microcode--heck the same RISC CPU by the same vendor may have different microcode.

So:

- Sure, a RISC CPU can implement Intel x86 instructions in its microcode. But if you're thinking there could be a universal microcode "micro-binary" that implements the x86 ISA and can be applied to any CPU - nope. Would be nice but again the microcode is specific to a particular CPU microarch. So far easier and cheaper to just have a JIT facility in the operating system convert x86 opcodes to the equivalent RISC CPU opcodes when it's being loaded. You pay this penalty once if your OS does this right and caches the converted binary, and then you're done with it.

- If you want to expose the microarch so it can be directly programmed - that'd be interesting, but you're probably not going to make better decisions than the microarch in so far as keeping all the engines in the CPU 100% utilized. You might make it more secure, but it's a lot of work. It's probably more easier and profitable just to develop an ASIC for your application at that point, or if you're Apple, develop your own CPU.

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.

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...

I think it would be better to abandon x86 than to try to understand it :)

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.