
Inside the AMD Microcode ROM [video] - DyslexicAtheist
https://media.ccc.de/v/35c3-9614-inside_the_amd_microcode_rom
======
atq2119
According to a question at the end, this is about _very_ old CPUs, K8/K10,
because the newer ones authenticate microcode updates with public key
cryptography which hasn't been broken. Still pretty amazing stuff.

~~~
loeg
Yeah, the description says "up to 2013." I think that's likely a bit more
recent than K10 but I don't know.

~~~
TazeTSchnitzel
That's just the tail end of K10 production (201 _2_ according to Wikipedia).
Its successor, Bulldozer, came out in 2011, but a new architecture being out
doesn't mean its predecessor immediately stops production.

------
snovv_crash
I wonder whether it would be possible to add aftermarket AVX-512 instruction
handling? Not for performance necessarily, but for compatibility.

~~~
ip26
We have robust support for alternate code paths based on CPU flags after many
years of this kind of thing. Is that really necessary or useful?

Custom microcode handling is a lot more brittle and chip- specific yet nearly
equivalent to overloading in software your call to some avx512 op.

~~~
raverbashing
You're right, it isn't needed

The "last time" this was done was in the x87 days, where if the math
coprocessor wasn't installed you could trap the corresponding interrupt and
handle it to emulate the instructions.

~~~
bpye
This is done for MIPS FP emulation too - [https://www.linux-
mips.org/wiki/Floating_point#The_Linux_ker...](https://www.linux-
mips.org/wiki/Floating_point#The_Linux_kernel_and_floating_point)

------
cafxx
I wonder if it would be possible to dump, from microcode, the contents of the
microcode ROM. This would neatly sidestep the problems inherent in decoding
the ROM contents from pictures of decapped chips.

------
choonway
Is it possible to hack the microcode so that it can run ARM assembly natively?

~~~
bayindirh
It would be hard, because the ISA is tightly bound to the underlying silicon's
structure.

Some of the commands cannot be translated to the silicon effectively or not at
all.

e.g.: MIPS have 64 x 64bit registers. You can use any of them as a source or a
destination, however x86 always designates EAX as the ALU accumulator. This
has some profound effects on silicon design.

~~~
gpderetta
> x86 always designates EAX as the ALU accumulat

Actually no. After decoding there is nothing special in the aex register.

AMD at some point was going to release K10 which was basically Zen but with an
ARM decoder. It got cancelled when Zen proved viable and AMD decided it was
better to compete with Intel than all the ARM vendors.

~~~
bayindirh
> Actually no. After decoding there is nothing special in the aex register.

The microcode, or specifically the modern x86 processors, are using register
renaming to move things around, but the actual ASM commands imply that the
results should end in EAX register. You cannot arbitrarily do a MUL and get
the result from EBX for example [3]. i.e. x86 assembly dictates where the
results should end in.

AMD played with two ideas: A pure ARM core, and a hybrid x86 core with ARM co-
processor. The ARM core missed the performance targets [0], and they also
abandoned the ARM accelerated x86 core [1], but I don't know why.

They never intended to go full TransMeta and transcode the x86 ASM into
something proprietary or ARM.

Bonus: It seems they are _still_ muling the idea of X86/ARM hybrid [2].

[0]:
[https://www.theregister.co.uk/2018/11/27/amazon_aws_graviton...](https://www.theregister.co.uk/2018/11/27/amazon_aws_graviton_specs/)

[1]: [https://www.extremetech.com/computing/205078-amds-project-
sk...](https://www.extremetech.com/computing/205078-amds-project-skybridge-
the-armx86-hybrid-core-is-officially-dead)

[2]:
[https://www.reddit.com/r/AMD_Stock/comments/8x4sba/the_retur...](https://www.reddit.com/r/AMD_Stock/comments/8x4sba/the_return_of_the_x86arm_hybrid/)

[3]:
[https://c9x.me/x86/html/file_module_x86_id_210.html](https://c9x.me/x86/html/file_module_x86_id_210.html)

------
shmerl
Why is AMD microcode not open source to begin with?

~~~
jshap70
because there's a lot of proprietary stuff in microcode that's used for
accelerations. gfx drivers too. it's the reason the closed amd drivers are so
much faster than the open mesa ones.

~~~
shmerl
_> it's the reason the closed amd drivers are so much faster than the open
mesa ones._

On the contrary, Mesa is faster than their blob. AMD themselves are working on
replacing blob with Mesa in the long term.

Firmware doesn't offer any acceleration advantages, it's used for different
purposes.

~~~
jshap70
yeah... I don't know what numbers you're looking at but that's not true in the
general case. and this isn't firmware, it's microcode. firmware is already on
the chip. microcode is used so the os can take advantage of chip specific
features, like security patches or even acceleration.

~~~
atq2119
Do you have actual benchmarks which show the closed source OpenGL driver
significantly faster than the open source one? In Phoronix benchmarks I've
seen, the open source driver beats the closed source one by a large margin.

~~~
jshap70
[https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-P...](https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-
PRO-16.40-Deus-MD)

~~~
shmerl
That's years ago and is outdated. Today Mesa beats the blob point blank,
thanks to AMD themselves working on optimizing radeonsi.

