In a logical, ordered world, the HTT bit in CPUID would indicate a processor with Hyper-Threading Technology enabled. But of course the world with Intel inside is anything but logical.
The actual meaning of the HTT bit changed several times over the years. Tracking exactly how it changed is difficult without all editions of Intel’s CPUID documentation (initially a standalone document, folded into the SDM in 2012), but there’s enough left to get a good idea.
Hyper-threading was introduced in the 180nm Foster MP Xeon in February 2002. That was the server version of the original Pentium 4 Willamette NetBurst implementation. Back in May 2002 (the oldest CPUID document with the HTT bit included that I could find), Intel said: HTT: This processor’s microarchitecture has the capability to operate as multiple logical processors within the same physical package. This field does not indicate that Hyper-Threading Technology has been enabled for this specific processor. To determine if Hyper-Threading Technology is supported, check the value returned in EBX[23:16] after executing CPUID with EAX=1. If EBX[23:16] contains a value > 1, then the processor supports Hyper-Threading Technology.
In other words, the HTT bit never meant that hyper-threading is enabled, or even that a given CPU is hyper-threading capable. It was a misnomer from the beginning.
And indeed, as the CPUID dumps here show, Northwood P4s with and without HT had the HTT bit set; the difference was in EBX[23:16] (indicating 1 logical processor for standard CPUs vs. 2 for HT-enabled models).
Intel changed the definition of the HTT bit over time. In May 2012, Intel said: HTT: Multi-Threading: The physical processor package is capable of supporting more than one logical processor. This field does not indicate that Hyper-Threading Technology or Core Multi-Processing (CMP) has been enabled for this specific processor. To determine if Hyper-Threading Technology or CMP is supported, compare value returned in EBX[23:16] after executing CPUID with EAX=1. If the resulting value > 1, then the processor supports Multi-Threading.
When Intel introduced dual-core CPUs without hyper-threading, the HTT bit was still used in exactly the same way as for single-core CPUs with hyper-threading. That makes perfect sense (other than the poorly chosen name), because in both cases there is a single physical package with two logical processors, and software needs to treat both cases largely the same.
The HTT bit alone therefore means almost nothing—it might be set on a single-core CPU without hyper-threading, and it will be set on single-core CPU with hyper-threading, multi-core CPU without hyper-threading, as well as a multi-core CPU with hyper-threading. Other CPUID data must be used to distinguish between those cases, as the information associated with the HTT bit only indicates the number of logical processors, not how they are structured.
As of October 2017, Intel now says: HTT: Max APIC IDs reserved field is Valid. A value of 0 for HTT indicates there is only a single logical processor in the package and software should assume only a single APIC ID is reserved. A value of 1 for HTT indicates the value in CPUID.1.EBX[23:16] (the Maximum number of addressable IDs for logical processors in this package) is valid for the package.
Intel appears to be unwilling to change the name of the HTT bit, but the poorly chosen moniker is now fully exposed: The definition of the HTT bit does not even mention hyper-threading at all.
It’s worth mentioning that the original Willamette P4 apparently set EBX[23:16] to 1 even though the HTT bit was not set. In other words, EBX[23:16] may contain valid information on some processors even though it’s not declared as valid via the HTT bit. That was undocumented behavior, and was also found in single-core Yonah CPUs (but not Banias/Dothan Pentium M).
All in all, this is a case where the documentation was never exactly wrong, it just evolved so much that the original name of the HTT bit doesn’t make any sense anymore, if it ever did.
Yea, I think it was influenced by processor licensing code in for example Windows XP.
@Yuhong Bao:
How so?
Windows XP tried to count the number of physical processors instead of threads in a hyper-threading processor for licensing purposes. It was obvious the same code could be useful for multi-core too.
@Yuhong Bao: That doesn’t make sense. Why would it make a difference how many processors\cores Windows was running on? It’d still only be one copy of Windows…
Windows XP Home could only use one core. The virtual core created by SMT was supported by XP Home. There were a few other cases where per core licensing costs happened like Oracle in 2001 but almost all ignored the existence of hyperthreading. Charging the price of a second core for the limted effects of hyperthreading would have killed hyperthreading. Oracle 9i standard was $15,000 per processor and hyperthreading made much more sense in the database market than to consumers with a word processor or web browser.
@Sean McDonough: Many editions of Windows impose limits on the number of “processors” licensed. For example, workstation/professional editions typically limit to 2 processors.
@Yuhong Bao: What source do you have that Intel designed around Windows OS limits? The information I have is that Intel pressured database vendors to not count Hyperthreading against license limits for the Xeons that first supported it and then pushed MS to do the same for XP Home when HT moved to the consumer market. HT was not supplied to the business desktop market in 2004 but the home user could buy a CPU with it. MS went along with that one because supporting HT was one of the few inducements for XP Home over Win 98SE.
Intel was always in favor of other companies putting in licensing terms that make the purchase of more expensive Intel chips the best TCO option.
I am talking about what happened *after* hyperthreading was created.
@Yuhong Bao: You seem to be making an oblique reference to something I can not place. Could you perhaps provided a more detailed reference?
Well, it should be obvious that the same licensing code that was added for hyper-threading (as you mentioned) can be used for multi-core etc.
This bug is worth mentioning BTW:
https://support.microsoft.com/en-us/help/958244/the-system-may-stop-responding-when-you-restart-a-windows-xp-based-mul
@Yuhong Bao: It still doesn’t make sense (no matter how many processors/cores your computer has, it’s still only running a single copy of Windows), but OK.
@Sean McDonough: It may be one copy of Windows per system but I doubt MS wants people to use $100 Home in the place of $6,000 Server Datacenter. On the other hand, no one will pay more for OS than hardware.
It was an interesting time around 2000 when Alpha, Itanium, and Power had roadmaps leading to multiple cores per socket, each also having SMT. Figuring out how to adjust pricing for the increased number of lower performing* reported cores was a frequent topic. Surprised a lot of people by how fast the introductions came with dual core Power4 in 2001 and Hyperthreading in 2002.
* Lower performing compared to the same design in single core without SMT per socket. Power limits, memory limits per socket, SMT only generating 20% performance boost in ideal situations all means density might be amazing but total performance isn’t.