Re: Code archaeology - 3DNow vs Pending Break Enable

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 25/11/2025 10:40 pm, Andrew Cooper wrote:
> 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@zytor.com>,
> 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?

Actually, on further consideration, the code layout on the preceding
commit (2.4.0-test11pre4 079dff3979df846 in the mirror) might explain
things.

X86_FEATURE_AMD3D was 0x80000000, and init_cyrix() was putting it in
c->x86_capability (because there was only a single bitmap) one case by
probing, and one case from reading it it out of extended CPUID.

So, this looks like it may have been a logical issue prior to "Massive
cleanup" separating the c->x86_capability field into an array, and ought
to have been cleaned up too.

In which case I think it's safe to retire the logic.

~Andrew