Code archaeology - 3DNow vs Pending Break Enable
From: Andrew Cooper
Date: Tue Nov 25 2025 - 17:40:18 EST
Hello,
init_amd() has the following curious code:
/*
* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
* 3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway
*/
clear_cpu_cap(c, 0*32+31);
as has Centaur and Cyrix. Amazingly, besides formatting, this appears
to be unchanged since "Massive cleanup of CPU detection and bug
handling; Transmeta CPU detection, H. Peter Anvin <hpa@xxxxxxxxx>,
November 2000".
https://github.com/schwabe/davej-history/commit/67ad24e6d39c3bc4618e7eb0563ccde3d76d0a51#diff-ab4c065cef7ebcd6d255c47ed4c3c0a77da8ad3df004dab9a183cc88814730ff
is the only working mirror I can find online.
When AMD added 3DNow, it was only in extended CPUID.
https://datasheets.chipdb.org/AMD/All%20CPU/20734j.pdf notes that other
vendors implemented 3DNow, and Centaur does have extra logic to
re-activate 3DNow.
I realise I'm asking a lot, but do you remember why this clear of PBE
was added?
It looks out of place even at the time of adding. The x86_capability
backing memory was zeroed shortly before, and only only written into by
a correct looking cpuid(1) invocation.
Was there really a CPU which misreported it in basic CPUID, or is there
some other reason for it?
Thanks,
~Andrew