Intel's "redundant prefix issue"

Posted Nov 27, 2023 15:28 UTC (Mon) by paulj (subscriber, #341)
In reply to: Intel's "redundant prefix issue" by farnz
Parent article: Intel's "redundant prefix issue"

I don't buy it changes completely from generation to generation. Intel architects have described how functional blocks are re-used again and again. Didn't you link to a talk with a P6 architect who was proud that some of the P6 core functional blocks had survived to CPUs many generations later?

Sure, some specifics - bit patterns to access something - could change, but the behaviour of much of the functional block is going to stay the same. And you're telling me Intel doesn't have internal documentation for microcode writers? :)

I'd accept things are far from perfect for what you'd want to release as a supported external interface. But that isn't what's asked for. Docs suck for much of the open-source world too - doesn't stop people hacking on it, or even /creating/ such documentation (and some basic interfacing information can be auto-generated from HDLs).

Intel's "redundant prefix issue"

Posted Nov 27, 2023 15:42 UTC (Mon) by farnz (subscriber, #17727) [Link] (2 responses)

But it's those specifics that you care hugely about, and not the broader functional units; great, the LSQ is the same, but now you've got a completely different set of interactions with microcode to last time, because the hardware designers are confident in different bits of it, and have attached microcode hooks to different bits of the LSQ. And no, I don't believe Intel does have internal documentation for microcode writers; IME, microcode is written by people embedded in the CPU design team, and they use the actual design sources as the documentation.

I suspect that Intel doesn't have anything it can release as a microcode "interface"; you're asking them to write this documentation, unlock the microcode (making reverse engineering their CPUs easier for competitors) and for no gain to Intel. This isn't something Intel will do, for obvious reasons - it's all costs to them, for no gains, and it's stuff they have to redo for each generation.

Intel's "redundant prefix issue"

Posted Nov 27, 2023 16:28 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

Ok, fair enough, I'll defer to the more specific experience you and pizza have.

I still think that, even without _any_ documentation, if the microcode were at least user-replaceable, there would be clever people out there - outside of AMD and Intel - who would start to reverse engineer at least some of its functions, and we'd get some useful things out of it. There'd be bored EEE students writing fuzzers, measuring the visible changes on x86 ISA, and mapping out at least some subset of the microcode to hit on something useful.

Intel's "redundant prefix issue"

Posted Nov 27, 2023 16:35 UTC (Mon) by farnz (subscriber, #17727) [Link]

I'd certainly agree that people would reverse engineer the microcode and do things with it - I'm just not sure how I'd write that as a positive for Intel, since most of them will be aiming to either find a cool new vulnerability in Intel's designs, or trying to work out how Intel manages to be "better" than their preferred design at doing something.

We only got what we got for GPUs because Intel (and later AMD) needed something to get them design wins over the leading GPUs on the market, and the business case was that, while writing OSS drivers would help competitors reverse-engineer their designs, having OSS drivers would result in them getting sales to customers who see OSS drivers as a positive - and with ATI and nVidia winning (for Intel) and later nVidia dominating over AMD, they valued those design wins over protecting themselves from reverse-engineering. And this was especially clear since people could, and did, reverse engineer nVidia's closed drivers because they had documentation for the CPUs they ran on, even though they didn't have documentation for the GPUs.

Intel's "redundant prefix issue"

Posted Nov 27, 2023 15:52 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> Sure, some specifics - bit patterns to access something - could change, but the behaviour of much of the functional block is going to stay the same. And you're telling me Intel doesn't have internal documentation for microcode writers? :)

These "bit patterns to access something" is what 95% of these "microcode updates" actually manipulate. A typical change is to invert a chicken bit that [dis]ables a bit of hardwired logic, but only when bits #12213 and #21123 are set, and the rest is writing a _patch_ to the microcode baked into ROM to deal with the changed reality.

Even in simple/trivial designs there can be literally dozens of these bits that mean nothing without detailed design information. -- To provide an example from pop-ish culture, What does the switch labeled "SCE to AUX" do, and when would it matter? Why not always run with it turned on?

(And I speak about this from experience, having a couple of SoCs under my professional belt, including devloping patches for ROM'd code. One chicken bit in particular saved us from having to do a complete respin due to a problem with an untestable-until-silicon-gets-back analog component.)

Intel's "redundant prefix issue"

Posted Nov 27, 2023 16:13 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

Thanks for the comment, informative examples. Cheers.

Just to be clear, that's what I had in mind. The bit pattern to change the FROB function from the FOO mode to BAR mode in the FROBBASHER functional unit could be wired up to bit-pattern 12213 in one implementation and 54213 in another. However, this does not present some fundamental obstacle to documenting the FROBBASHER block and how it could be programmed from micro-code - surely that is obvious?

The answer is the block is documented as having a FROB_MODE setting, which selects either the FOO or BAR mode, which implies <etc, etc.>. Then the internal architecture documentation for the Super-Duper-Micro-Electronics SDME 20001 specifies it uses the FOBBASHER v2.1 block, with its various programmable operations wired to:

...
FROB_MODE 12213
...

And the SDME 20100 similar, with (say)

....
FROB_MODE 54213, with X set to 1.

There are, 100% for sure, a number of fairly well re-used functional units in Intel CPUs. And further, a number of such functional units are to implement things that are very common and similar and well-understood in high-level operation across all CPUs. And particularly on x86 CPUs, with their CISC ancestry, with a number of (fairly new!) instructions that are simply there to optimise logical constructs of the software which are implemented in micro-code (VGATHER, VBLEND, etc.).

Intel's "redundant prefix issue"

Posted Nov 27, 2023 16:17 UTC (Mon) by paulj (subscriber, #341) [Link]

I.e., there are specialised logical optimisations that one could implement as a macro-instruction entirely on top of even the existing subset of intel instructions that are /documented/ as single-micro-op (and have been for a number of generations) that could speed up certain applications. Applications too niche for intel/AMD to go add an instruction themselves.

Intel's "redundant prefix issue"

Posted Nov 27, 2023 16:26 UTC (Mon) by farnz (subscriber, #17727) [Link]

That's not how reused functional units work in a CPU, though. You have a FROBBASHER functional unit, whose mode bits are set by the CPU in different ways in different implementations; so, in the SDME 20001, FROBBASHER takes its mode bits directly from microcode, while in the 20100 where the FROBBASHER is also used by non-microcoded operations, its mode bit comes from elsewhere, unless the microcode execution engine is in control in which case it comes from a hidden state register (not from the microcode), and you now have to document that hidden state register and how it's controlled by the system.