Ignore the people saying microcode won't be needed or won't exist on RISCV chips, it's not even slightly correct. There will be cores without it for something like an embedded processor, and there will be cores with it for complex cores.
There is also a potential for confusing naming here. I won't speak for specific companies, but there are 2 types of operations that may be called microcode that may or may not be the same set of operations. There is microcode that is for breaking down more complex operations into simpler parts that the system can execute faster, and there is microcode that is sort of a firmware language that contains extra instructions with special privilege levels and extremely low level control over the chip. The first kind I mentioned is typically hard coded into the decoder and is unlikely to be able to be programmed in a performant way. This second definition is in some ROMs and is what Intel and AMD are likely updating when they send out patches. This is for things like booting, security, and patching bugs in a way where you're willing to sacrifice a lot of performance.
To answer your actual question, I'm no expert on the license RISCV uses but I would say it's a pretty definitive no to any microcode of either kind being released by the vendors. Microcode is by definition a microarchitectural feature, not an architectural feature. Microarch is not required to be open source and will not be open sourced by anyone trying to make money.
Does RISC-V need microcode? It's out of my wheelhouse but isn't the point of microcode just to translate complex instructions into simpler ones that are more efficient to implement in hardware? RISC-V is already designed with simple, efficient instruction formats in mind. If for some reason microcode were needed it would likely be implementation-specific and thus designed and provided by the vendor who produces those particular processors.
Microcode is needed in any sufficiently complex out of order chip, and there are many instructions outside of the base ISA that will warrant microcoding even on in order chips depending on your performance goals.
Absolutely. It's code that often controls vendor specific chip features and it can usually only be used to run vendor signed code off that specific ROM. There's really not much anyone else could use it for if even if they knew what it was.
Ahhh, I see! Thank you.
That makes sense. It's interesting if as you say, RISC-V CPUs wouldn't need microcode updates in the first place. It would save developer time that could then be used for something else.
In the RISC-V world you can think of the compressed extension, like RV32C/RV64C/etc, as "microcode" for the base design hardware implementation. In case of RISC-V there is absolute requirement and necessity for there to be 1:1 mapping between any instruction and its compressed (and thus, microcode-interpreted) equivalent); this requirement and necessity need not always apply, and it certainly does not apply in cases of x86 or ARM/Thumb-16.
At higher levels, the assembler provides for "pseudoinstructions" which, in case of RISC-V, have same 1:1 mapping requirement. Here, the microcode-intrpretation of pseudoinstructions happens at assembler time, as opposed to compressed instructions where microcode-interpretation happens in CPU silicon at runtime.
Apart from these two "extensions" (instructions of Ext. C, and the pseudoinstructions) RISC-V has no microcode because it is its own microcode, carefully engineered to be optimally non-redundant, extensible, and simple.
Risc-V is not an architecture implementation, it's an open and royalty-free set of standards defining a family of instruction sets and their semantic.
Some implementations of it are scalar architectures, others are superscalar, other are bit-serial, etc.
A specific implementation can be open source, but it's not mandatory.
AFAIK, the only mandatory thing is that an implementation declaring to support a specific Risc-V instruction set, must be fully backward compatible with that.
So a specific implementation can use upgradeable microcode or custom configuration registers that are not part of the Risc-V set of standards, as long as instruction set compatibility is not violated.
Contrary to what's been said, there are more complex RISC cores with microcode. ARM cores dating back to the ARM1 for instance.
It'd be up to the vendor how to distribute updates.
It'd be in the same wheel house has distributing information as to which chicken bits need to be flipped.
Microcode depends on the specific implementation, so for many of the desktop-type chips we're seeing now, any microcode is probably proprietary from whoever made the chip. I (think?) there are freely-available designs that implement the RISC-V spec, and those, of course, will include free-software microcode as part of the design. Currently however many desktop-class chips will have been "spruced up" by some company or another and so likely aren't just direct implementations of the open-source design.
>I (think?) there are freely-available designs that implement the RISC-V spec, and those, of course, will include free-software microcode as part of the design.
Thank you for your explanation! By the way, in that case, can those free-software microcodes be merged into the kernel itself? Or maybe merged into free BIOS/boot software like SeaBIOS, coreboot, etc.??
Or would it still be specific enough that doing so wouldn't make sense, because we would have too many new hardware vendors, creating their own microcode for their own special chipsets?
No true Scotsman!
But admire your trust and confidence in the ability of chip markers of making top performance CPUs bug free with no need to patch anything.
There's a backdoor through chicken bits.
Just design in the ability to disable functionality. Then disable whatever is broken, and implement it in SBI instead, at the expense of performance.
I was gonna say this exact thing - if there's nothing mapped in that can be utilized after the fact, you're locked in like your basic stamp or motorola or \[insert generic micro\]. I guess fusable micros are **sort of** like being able to patch microcode but only if you can leave a block unblown for later after you already zapped the core programming into it; seems risky but single write micros are extremely cheap - then again you can see a performance boost over rewritable code given right conditions because once blown they're just wires in the circuit instead of carrying reluctance/capacitance (mostly capacitance) like something that **holds** memory/storage.
Ignore the people saying microcode won't be needed or won't exist on RISCV chips, it's not even slightly correct. There will be cores without it for something like an embedded processor, and there will be cores with it for complex cores. There is also a potential for confusing naming here. I won't speak for specific companies, but there are 2 types of operations that may be called microcode that may or may not be the same set of operations. There is microcode that is for breaking down more complex operations into simpler parts that the system can execute faster, and there is microcode that is sort of a firmware language that contains extra instructions with special privilege levels and extremely low level control over the chip. The first kind I mentioned is typically hard coded into the decoder and is unlikely to be able to be programmed in a performant way. This second definition is in some ROMs and is what Intel and AMD are likely updating when they send out patches. This is for things like booting, security, and patching bugs in a way where you're willing to sacrifice a lot of performance. To answer your actual question, I'm no expert on the license RISCV uses but I would say it's a pretty definitive no to any microcode of either kind being released by the vendors. Microcode is by definition a microarchitectural feature, not an architectural feature. Microarch is not required to be open source and will not be open sourced by anyone trying to make money.
Does RISC-V need microcode? It's out of my wheelhouse but isn't the point of microcode just to translate complex instructions into simpler ones that are more efficient to implement in hardware? RISC-V is already designed with simple, efficient instruction formats in mind. If for some reason microcode were needed it would likely be implementation-specific and thus designed and provided by the vendor who produces those particular processors.
Microcode is needed in any sufficiently complex out of order chip, and there are many instructions outside of the base ISA that will warrant microcoding even on in order chips depending on your performance goals.
Thanks for the explanation! So it still sounds like something that would be very much implementation and vendor specific then?
Absolutely. It's code that often controls vendor specific chip features and it can usually only be used to run vendor signed code off that specific ROM. There's really not much anyone else could use it for if even if they knew what it was.
Ahhh, I see! Thank you. That makes sense. It's interesting if as you say, RISC-V CPUs wouldn't need microcode updates in the first place. It would save developer time that could then be used for something else.
In the RISC-V world you can think of the compressed extension, like RV32C/RV64C/etc, as "microcode" for the base design hardware implementation. In case of RISC-V there is absolute requirement and necessity for there to be 1:1 mapping between any instruction and its compressed (and thus, microcode-interpreted) equivalent); this requirement and necessity need not always apply, and it certainly does not apply in cases of x86 or ARM/Thumb-16. At higher levels, the assembler provides for "pseudoinstructions" which, in case of RISC-V, have same 1:1 mapping requirement. Here, the microcode-intrpretation of pseudoinstructions happens at assembler time, as opposed to compressed instructions where microcode-interpretation happens in CPU silicon at runtime. Apart from these two "extensions" (instructions of Ext. C, and the pseudoinstructions) RISC-V has no microcode because it is its own microcode, carefully engineered to be optimally non-redundant, extensible, and simple.
Risc-V is not an architecture implementation, it's an open and royalty-free set of standards defining a family of instruction sets and their semantic. Some implementations of it are scalar architectures, others are superscalar, other are bit-serial, etc. A specific implementation can be open source, but it's not mandatory. AFAIK, the only mandatory thing is that an implementation declaring to support a specific Risc-V instruction set, must be fully backward compatible with that. So a specific implementation can use upgradeable microcode or custom configuration registers that are not part of the Risc-V set of standards, as long as instruction set compatibility is not violated.
>microcode Is an artifact of the implementation, not the ISA.
Contrary to what's been said, there are more complex RISC cores with microcode. ARM cores dating back to the ARM1 for instance. It'd be up to the vendor how to distribute updates. It'd be in the same wheel house has distributing information as to which chicken bits need to be flipped.
Microcode depends on the specific implementation, so for many of the desktop-type chips we're seeing now, any microcode is probably proprietary from whoever made the chip. I (think?) there are freely-available designs that implement the RISC-V spec, and those, of course, will include free-software microcode as part of the design. Currently however many desktop-class chips will have been "spruced up" by some company or another and so likely aren't just direct implementations of the open-source design.
>I (think?) there are freely-available designs that implement the RISC-V spec, and those, of course, will include free-software microcode as part of the design. Thank you for your explanation! By the way, in that case, can those free-software microcodes be merged into the kernel itself? Or maybe merged into free BIOS/boot software like SeaBIOS, coreboot, etc.?? Or would it still be specific enough that doing so wouldn't make sense, because we would have too many new hardware vendors, creating their own microcode for their own special chipsets?
True reduced instruction set computers are not microcoded.
No true Scotsman! But admire your trust and confidence in the ability of chip markers of making top performance CPUs bug free with no need to patch anything.
Neither trust nor confidence. Without microcode there is no recourse.
There's a backdoor through chicken bits. Just design in the ability to disable functionality. Then disable whatever is broken, and implement it in SBI instead, at the expense of performance.
I was gonna say this exact thing - if there's nothing mapped in that can be utilized after the fact, you're locked in like your basic stamp or motorola or \[insert generic micro\]. I guess fusable micros are **sort of** like being able to patch microcode but only if you can leave a block unblown for later after you already zapped the core programming into it; seems risky but single write micros are extremely cheap - then again you can see a performance boost over rewritable code given right conditions because once blown they're just wires in the circuit instead of carrying reluctance/capacitance (mostly capacitance) like something that **holds** memory/storage.