5 ms·

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

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)...
- tenebrisalietum 5y ago
  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.

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

tenebrisalietum 5y ago
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.