[ajross]

> legacy mode only cruft (which is not as much as you might think, but tends to be in the critical data path)

I'm curious about what you're thinking about here. In fact almost all the code paths for user mode code are running out of the uOp cache in modern devices and completely decoupled from the legacy stuff. And even in the kernel, doing locking and mode switching on the normal paths doesn't hit any major fallbacks. There's a ton of microcode and other legacy handling for odd stuff for sure, but really not on performance loads.

[monocasa]

One example: the segmentation hardware needs to evaluated in the TLB lookup path between L1 and L2. Even special casing base=0 length=4G or not (and do the slow path in the not case) and just adding an extra mux there is still a minor burden in the designs I've heard about.

Also, the instruction decode cases for 16bit mode is still in the main instruction decoder and not ucode AFAIK. They're almost the same encoding, and there's not enough ucode pace for it all, but removing those cases from the muxes there would help power consumption. Yes, you run out of the uOp cache a lot of the time, but not as much as you might think, and AFAIK the instruction decoder is still cranking away in the background because you want it to be immediately available as soon as an instruction is not in the uOP cache. That means the power efficiencies can be gained there.

[exikyut]

I'm incredibly late with this reply and I completely understand that you may never see it, but I'd be extremely interested to dump myself in the deep end of stuff that's on the same wavelength as what you're describing, if you have any suggestions for resources I might be able to follow up on. Thanks!