[DeathArrow]

>However, since that time, all modern CPUs have turned RISC-like, by internally using a reduced instruction set and translating the ISA opcodes into internal commands, some implemented using CPU microcode.

Is there a way Intel can expose microcode and commands to outside so compilers can directly target them instead of X86 instruction set?

If yes, would there be anything to gain or lose?

[wongarsu]

One advantage of not exposing microcode is that newer processors can add support for new microcode instructions and map existing X86 instructions to them. In a sense there's a tiny JIT in the CPU that turns X86 into processor-optimized code.

The disadvantage is of course that this is complex to do in silicon, and the CPU might lack some insights that the compiler had. As I understand it Itanium was HP's and Intel's attempt to give a lot more power to the compiler, with an instruction set that better matches what's going on under the hood. But we all know how that ended: performance was lackluster and the Itanic was nothing but a waste of money for everyone involved.

GPUs have successfully moved the microcode translation one layer up, you generally compile to an intermediate ISA (let's call it a bytecode) and when you load the program (or shader) the GPU driver translates it to GPU-specific instructions. But that model doesn't easily translate to CPUs.

[zinekeller]

> Is there a way Intel can expose microcode and commands to outside so compilers can directly target them instead of X86 instruction set?

Maybe, but MOV is still MOV, so Intel, for the most part, is simply using a subset of x86 (or AMD64) instructions. Except for a few proprietary commands used to implement the more complex commands, most simple instructions are implemented as-is and are passthroughed anyways.

> If yes, would there be anything to gain or lose?

Gains: Very slight faster performance (reduced lookup is always great, but realistically it doesn't matter unless you're doing supercomputer stuff).

Losses: It's pretty much like the kernel land of Linux or NT's undocumented functions: subject to change, fully not supported. Also, cannot be done on the current CPU families anyway since that the microcode can't be updated in such a way that it is worth it.

[anamax]

Micro-ops often have more bits than the ISA they're implementing, so you'd pay a program-size penalty.

Moreover, Intel (and I assume AMD), will take a sequence of micro ops corresponding to a sequence of "instructions" and optimize the micro-op sequence based on dynamic usage, together with "undo" for when the usage assumptions are wrong.

[TonyTrapp]

From my understanding, this microcode may and will change between processors, so you lose the possibility of running your code on more than specific CPU type / generation.

[grishka]

Isn't microcode specific to a particular microarchitecture, that can, and often does, change between CPU model generations?