5 ms·

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 gen

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
      In physical terms, I probably would not count it. However if I were doing emulation, I would have to count it because it is a register case that has to be addressed. Just like the D register has to be dealt with on a 6809. My own personal way to resolve this has always been to determine whether or not a given register specification, that can be addressed somehow, brings new information not contain in any other register specification, to the table. Fact is, CPU designers do all kinds of crazy things with registers. They overlap, they may be indirect, like not directly addressable, but still there as consideration for the programmer. Think about something like the REP instruction found on some CPUs. There's a little circuit it keeps track of account, and some rules, and account may be a register that may or may not be directly addressable any other way. My general take on this article is, "wow, that's a lot of registers!" We can all quibble about what the quantity of a lot is, and it's all good fun, and I don't think it means anything really.
- cardiffspaceman 6y ago
  The emulator has to handle and the testing infrastructure has to have tests for each subregister and how it affects its parent register. You have to prevent and detect design-level oversights such as "AH is not the LSB of AX/EAX/RAX and my design only accounts for LS-whatever subregisters". Your point that they can't be distinct holds, but but if they were distinct they would have less impact on the engineering than they will have as subregisters.
spearo77 6y ago
A reference for Rosetta being a translation, rather then emulation. "Rosetta is a translation process" https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment?language=objc https://developer.apple.com/documentation/apple_silicon/abou...
- saagarjha 6y ago
  Rosetta is an emulator.
  - kergonath 6y ago
    “an emulator is hardware or software that enables one computer system (called the host) to behave like another computer system” (Wikipedia). This is not the case for Rosetta 2, which does a translation pass before running the generated ARM binary. No x86 code is run.
    - userbinator 6y ago
      That's just the difference between a JIT and not - something like QEMU in the other direction doesn't "run" ARM code either, but in the end it really doesn't matter and is only a minor pedantry.
    - icedchai 6y ago
      I'd argue that "translation" is an implementation detail of emulation. Your translated app still thinks it is x86-64 (witnessed by running "uname -a" in a Rosetta terminal.)
pizza234 6y ago
The title "How many register can an x64-86 _address_" is probably more accurate and less controversial.
rbanffy 6y ago
> * How many bytes of register files does the OS have to save on task switches? (With this question, subregisters shouldn't be counted.) This is something that has been bothering me for some time now - actually since the mid-80's: why not implement multiple contexts as an index into a large register file? This way, a context switch would take the time it takes to write to the `task-id` register. It will impact latencies, but would the impact of having, say, 8 contexts not be smaller than having to hit L1 or L2 for the same data?
- scottlamb 6y ago
  Isn't that (part of) what hyperthreads do?
  - rbanffy 6y ago
    True, but at two per core (4 or 8 in more enlightened architectures), it's very meh. I would assume that, instead, a modern CPU tags decoded instructions in the reorder buffer with the virtual core number (and register set) it should be applied to. This way, the parallelism would be much easier to exploit.

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
    In physical terms, I probably would not count it. However if I were doing emulation, I would have to count it because it is a register case that has to be addressed. Just like the D register has to be dealt with on a 6809. My own personal way to resolve this has always been to determine whether or not a given register specification, that can be addressed somehow, brings new information not contain in any other register specification, to the table. Fact is, CPU designers do all kinds of crazy things with registers. They overlap, they may be indirect, like not directly addressable, but still there as consideration for the programmer. Think about something like the REP instruction found on some CPUs. There's a little circuit it keeps track of account, and some rules, and account may be a register that may or may not be directly addressable any other way. My general take on this article is, "wow, that's a lot of registers!" We can all quibble about what the quantity of a lot is, and it's all good fun, and I don't think it means anything really.
cardiffspaceman 6y ago
The emulator has to handle and the testing infrastructure has to have tests for each subregister and how it affects its parent register. You have to prevent and detect design-level oversights such as "AH is not the LSB of AX/EAX/RAX and my design only accounts for LS-whatever subregisters". Your point that they can't be distinct holds, but but if they were distinct they would have less impact on the engineering than they will have as subregisters.

spearo77 6y ago

A reference for Rosetta being a translation, rather then emulation. "Rosetta is a translation process" https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment?language=objc https://developer.apple.com/documentation/apple_silicon/abou...

saagarjha 6y ago
Rosetta is an emulator.
- kergonath 6y ago
  “an emulator is hardware or software that enables one computer system (called the host) to behave like another computer system” (Wikipedia). This is not the case for Rosetta 2, which does a translation pass before running the generated ARM binary. No x86 code is run.
  - userbinator 6y ago
    That's just the difference between a JIT and not - something like QEMU in the other direction doesn't "run" ARM code either, but in the end it really doesn't matter and is only a minor pedantry.
  - icedchai 6y ago
    I'd argue that "translation" is an implementation detail of emulation. Your translated app still thinks it is x86-64 (witnessed by running "uname -a" in a Rosetta terminal.)

pizza234 6y ago

The title "How many register can an x64-86 _address_" is probably more accurate and less controversial.

rbanffy 6y ago

> * How many bytes of register files does the OS have to save on task switches? (With this question, subregisters shouldn't be counted.) This is something that has been bothering me for some time now - actually since the mid-80's: why not implement multiple contexts as an index into a large register file? This way, a context switch would take the time it takes to write to the `task-id` register. It will impact latencies, but would the impact of having, say, 8 contexts not be smaller than having to hit L1 or L2 for the same data?

scottlamb 6y ago
Isn't that (part of) what hyperthreads do?
- rbanffy 6y ago
  True, but at two per core (4 or 8 in more enlightened architectures), it's very meh. I would assume that, instead, a modern CPU tags decoded instructions in the reorder buffer with the virtual core number (and register set) it should be applied to. This way, the parallelism would be much easier to exploit.