4 ms·

> I will count sub-registers (e.g., EAX for RAX) as distinct registers. My justification: they have different instruction encodings, and both Intel and AMD opti

• thesuitonym 6y ago
  Care to elaborate? Or is it, "just no"?
  • Macha 6y ago
    You can't independently store different values in the sub-registers. Storing in EAX clobbers what's in RAX.
    • colejohnson66 6y ago
      They are the same architectural register, but due to register renaming, they may not reside in the same physical transistors. That’s probably why the author supersets them.
      • fulafel 6y ago
        But the author dismisses registers that are microarchitectural details.
    • wtallis 6y ago
      This analysis does have some limited value for characterizing the complexity required in the processor's front end to decode instructions. Register renaming means it has somewhat less relevance to the difficulty a compiler faces with register allocation, and basically no relevance to the actual size of a processor's physical register file(s).
      • woodruffw 6y ago
        Yep, register allocation is another reason that I omitted for brevity's sake.
    • woodruffw 6y ago
      Author here: I don't think this is a good necessary condition for what makes something a register. For consideration: * Both x86 and other ISAs have registers that can't be stored to at all, like `k0` for the constant opmask and a whole bunch of read-only MSRs. But they can be read from wholly independently and as discrete registers. * There are lots of cases where registers can be programmed to clobber other registers, particularly in the performance counter and PAT MSRs. Sub-registers are definitely a stretch from the above, since they explicitly share bits in the x86 model. But then again, even the x86 model exposed to assembly programmers is a lie: the underlying microcode dynamically renames a large arena of anonymous registers at runtime, and subregisters like AL and AH have been separated in the microcode (to avoid some cases of partial register stalls) for over a decade.
      • khuey 6y ago
        MSRs are called "registers" sure but you can't actually perform any operations on them other than a load or a store, and you can't use them to stash random data outside of main memory because they affect the operation of the processor. `k0` (or e.g. MIPS's `r0`) are even worse, since you can't even write to them. That's not what most people care about when they talk about how many registers a processor has.
        • woodruffw 6y ago
          > That's not what most people care about when they talk about how many registers a processor has. I think most people do consider the instruction pointer and status word to be registers, despite also violating the constraints you specified. Most people probably don't think about MSRs at all, and so maybe just aren't interested in a count of them. But I'm interested in counting the different pieces of on-CPU state that would be necessary to faithfully model an entire x86 core, and both Intel and AMD refer to those bits of state as "registers."
      • caymanjim 6y ago
        It ruined the article for me. I skimmed a bit after that, but you started off so wrong that I dismissed the rest.
• cesarb 6y ago
  It makes sense if you're counting register _encodings_ (that is, how much ISA encoding space the registers use). But yeah, a more useful count would consider the sub-registers as part of the main register (and the same for other ISAs like 64-bit ARM, which does have a 32-bit view of its 64-bit general purpose registers), and would not consider registers outside each core (like the MTRR registers).
• andy_ppp 6y ago
  It depends on if you’re looking at this from an implementation in hardware vs software I’d say. The article specifically mentions Rosetta 2 as the context so I’m guessing the enumeration is more important if you intend to understand all the things Rosetta 2 has to implement.
• scottlamb 6y ago
  I think it's pointless to debate a methodology without a purpose. "How many registers does an x86-64 CPU have?" is interesting (to 58 voters so far) but too general to be useful for any particular purpose. Consider a couple alternate questions brought up in this thread: * How many bytes of register files does the OS have to save on task switches? (With this question, subregisters shouldn't be counted.) * How many registers does an emulator (such as Rosetta 2) have to implement and test? (Subregisters should be counted.) Even these one might argue aren't directly useful; when considering context switching, one could dig down further into how much of the context switching time is attributable to saving the registers, validate that with experiments across architectures, etc.
  • gpderetta 6y ago
    > How many registers does an emulator (such as Rosetta 2) have to implement and test? (Subregisters should be counted.) it still shouldn't because they can't be distinct in the emulator as writing on a subregister affects the larger register and viceversa.
    • ddingus 6y ago
      On the other hand, they do exist as a separate case, and have instructions that treat them as an individual register. There is precedent for all this too. Take the 6809, having 8 bit A and B accumulators. These can be addressed as D, a 16 bit register. D is not generally counted as it's own register because the D addressing does not point to anything new. A and B are counted as two registers. If somehow D brought new bits, say it was 24 bits long, then it would need to be counted.
      • shdon 6y ago
        Does that mean you would count AL, AH, but not AX (as it can be split into AL/AH and doesn't "bring new bits"), and then again would count EAX and RAX?
        • ddingus 6y ago