By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), July 19, 2022 1:29 pm
Room: Moderated Discussions
Adrian (a.delete@this.acm.org) on July 19, 2022 4:57 am wrote:
>
> It is likely that this does not offer much information about the micro-instruction
> format used in the mainstream Core and Xeon CPUs, which must be much more complex.
I'm not entirely convinced that the microcode on the big CPUs is necessarily all that much more complex. The bulk of the microcode is presumably all the horrid legacy stuff with call gates and task switching etc, and the problem space there is pretty much exactly the same for the small cores and the big ones.
And I've been told that people are very afraid to touch some of that code, because it's all incomprehensible legacy cruft, so presumably Intel would want to avoid making microcode changes that would force rewriting that code.
And from a performance angle, I'd expect CPU designers to look much more at making the uop cache work well, than at microcode optimizations. So I'd expect the bulk of effort to be on the uop side.
And yes, I'm sure there's a lot of commonality between the two, and there's probably pressure to make it easy to translate microcode to uops by the microcode sequencer. But you'd never want to go the other way, so it sounds entirely reasonable to me to just make sure that the uop format and capabilities is a proper superset of the microcode, and just "solve" the sequencer issue that way.
So for example, you say that there's a 13-bit immediate constant in the microcode VLIW, and I don't see why a big core would need a bigger one. Sure, the uops presumably need to have a bigger one (to encode the actual large 64-bit immediates that exist in x86 instructions), but it would seem entirely possible that the microcode doesn't support that at all.
So being a bigger core doesn't necessarily imply any need for bigger fields in microcode: the main use would presumably be for offsets within the complex x86 internal data structures (eg again things like that task switch data structure - the TSS - or for the offsets in the VMM structures etc).
And then the microcode sequences could just zero-extend (or sign-extend) it to whatever the uop cache format is. Same goes for register indexes etc.
Not that Intel describes the uop cache format either, so that just moves the "not documented" from one area to another ;)
Linus
>
> It is likely that this does not offer much information about the micro-instruction
> format used in the mainstream Core and Xeon CPUs, which must be much more complex.
I'm not entirely convinced that the microcode on the big CPUs is necessarily all that much more complex. The bulk of the microcode is presumably all the horrid legacy stuff with call gates and task switching etc, and the problem space there is pretty much exactly the same for the small cores and the big ones.
And I've been told that people are very afraid to touch some of that code, because it's all incomprehensible legacy cruft, so presumably Intel would want to avoid making microcode changes that would force rewriting that code.
And from a performance angle, I'd expect CPU designers to look much more at making the uop cache work well, than at microcode optimizations. So I'd expect the bulk of effort to be on the uop side.
And yes, I'm sure there's a lot of commonality between the two, and there's probably pressure to make it easy to translate microcode to uops by the microcode sequencer. But you'd never want to go the other way, so it sounds entirely reasonable to me to just make sure that the uop format and capabilities is a proper superset of the microcode, and just "solve" the sequencer issue that way.
So for example, you say that there's a 13-bit immediate constant in the microcode VLIW, and I don't see why a big core would need a bigger one. Sure, the uops presumably need to have a bigger one (to encode the actual large 64-bit immediates that exist in x86 instructions), but it would seem entirely possible that the microcode doesn't support that at all.
So being a bigger core doesn't necessarily imply any need for bigger fields in microcode: the main use would presumably be for offsets within the complex x86 internal data structures (eg again things like that task switch data structure - the TSS - or for the offsets in the VMM structures etc).
And then the microcode sequences could just zero-extend (or sign-extend) it to whatever the uop cache format is. Same goes for register indexes etc.
Not that Intel describes the uop cache format either, so that just moves the "not documented" from one area to another ;)
Linus
| Topic | Posted By | Date |
|---|---|---|
| Microinstruction format in older Atom CPUs | Adrian | 2022/07/19 04:57 AM |
| Microinstruction format in older Atom CPUs | zArchJon | 2022/07/19 11:51 AM |
| Microinstruction format in older Atom CPUs | dmcq | 2022/07/20 05:58 AM |
| Microinstruction format in older Atom CPUs | Linus Torvalds | 2022/07/19 01:29 PM |
| Microinstruction format in older Atom CPUs | Adrian | 2022/07/19 10:16 PM |