Yesterday I had the opportunity to test a recently acquired Athlon 1200 CPU (Thunderbird core, ceramic PGA package). I dreaded the first boot-up attempt because I have had rather bad experience with slightly newer Palomino and Thoroughbred OPGA processors—a surprisingly high percentage of them was DOA.

But the Thunderbird Athlon (two of them actually) with OPN A1200AMS3C sprang to life and worked just fine. While running some basic tests on the CPU, I noticed that it has a completely unknown CPUID bit set, specifically bit 18 in register EDX of CPUID leaf 80000001h.

The 8000xxxxh CPUID range was originally AMD specific and, among other things, used to indicate support for the 3DNow! instruction set in the AMD K6 processors.

When Intel introduced AMD64 support, they were more or less forced to support a subset of the 8000xxxxh CPUID range as well, for compatibility with existing AMD64 software. In any case, the Athlon CPU in question is from 2001 and pre-dates Intel’s x64 processors by several years.

The usually very reliable sandpile.org lists EDX bit 18 as “reserved”. I went through available AMD CPUID documentation but nope, bit 18 is listed as “Reserved on all AMD processors” in all the documents I could find.

Even better, AMD’s CPUID documentation lists the actual CPUID values for specific CPU models. For Athlon Model 4 (Thunderbird), CPUID leaf 80000001h register EDX is listed as C1C3_FBFFh when APIC is enabled. But the actual CPU returns C1C7_FBFFh in EDX—there is a one-bit difference, and it is precisely the mystery bit 18.

The fact that a random CPUID bit in the middle of used bits is “reserved” is usually a very good indication that the bit was used for something at some point, but either it never showed up in officially released CPUs or it briefly did (like this mystery bit 18) but was not documented.

Note that bit 19 was used to indicate multi-processing capability (or maybe really ECC memory support) in the Athlon MP, circa 2002. Bit 17 indicates PSE-36 (Page Size Extensions) and appears to have been added in Athlon Model 2 circa 1999. Bit 17 in the extended CPUID, like most of the lower bits, mirrors bit 17 in the “regular” CPUID (leaf 1, register EDX), defined by Intel.

Bit 18 in standard CPUID was used to indicate the short-lived PSN (Processor Serial Number) feature of Pentium III processors. However, it is unlikely that Athlon Model 4 implemented some sort of serial number capability, so the bit’s purpose was almost certainly something else.

So… what was that bit 18 for? Anyone?

Update: Soon after this post was published, sandpile.org was updated to show that bit 18 was intended to indicate ECC capability on AMD K7 processors. Which, to be honest, raises more questions than it answers. That said, I am confident that the sandpile.org information is accurate.

After reviewing Athlon datasheets, it is apparent that the original AMD-750 chipset and Slot A Athlons supported ECC memory. The capability was not advertised via CPUID, presumably because it could be assumed to be present.

ECC support (and the corresponding SCHECK pins) are also documented in Athlon Model 4/Thunderbird datasheets for Slot A. Note that Athlon Model 4 was the last to support Slot A and the first to support Socket 462. ECC support is likewise documented in the Duron Model 3/Spitfire datasheets (Socket 462 only).

Something curious happened with the Model 4 PGA Athlon datasheets. Revision G datasheet (Publication # 23792 Rev: G, October 2000) talks about ECC, the text is essentially identical to Slot A Athlon datasheets. However, Revision K datasheet (Publication # 23792 Rev: K, November 2001) has nothing about ECC or SCHECK pins. The document’s revision history makes absolutely no explicit mention of dropping ECC support; Revision H (March 2001) is probably where it happened, based on what was reportedly changed in that revision.

Athlon XP datasheets (starting with Model 6 aka Palomino) likewise include no mention of ECC. Only Athlon MP datasheets (Model 6/8/10) do.

It is clear from the published documentation that for Socket 462, AMD decided to make ECC support optional, hence it needed to be advertised through a CPUID bit. But for some reason, AMD decided to drop official ECC support from Model 4/Thunderbird Athlons, apparently before information about the CPUID bit was published.

At about the same time, AMD also decided to produce Athlon MP models with documented ECC capability and multi-processor support. ECC and MP capability was folded into one, indicated by extended CPUID bit 19. Bit 18 likely became obsolete because AMD dropped plans to make K7 processors with ECC support but no MP capability. So they retroactively pretended that ECC support for Socket 462 only existed in Athlon MP.

The situation was likely complicated by the fact that Athlon boards with non-AMD chipsets (VIA, ALi, nVidia) did not have any ECC memory support anyway. The typical Athlon customers was also likely interested in price/performance, not reliability, and was not interested in using ECC DRAM. AMD may well have decided that testing ECC support was not worth the effort, except for Athlon MP models.

If I had to speculate, there is a very good chance that the Athlons which set bit 18 do in fact support ECC, although I have no way to verify that. The one board I have which would support ECC (Tyan Thunder K7X Pro) unfortunately refuses to boot with ECC enabled even when an Athlon MP is in place (and yes, obviously with ECC DIMMs installed).