3 ms·

Eliminating GP registers from the ISA doesn't preclude any optimizations which could be done dynamically in the microarchitecture. The CPU would still be able t

Eliminating GP registers from the ISA doesn't preclude any optimizations which could be done dynamically in the microarchitecture. The CPU would still be able to deal with registers and caches internally, it's just that they won't be visible to the programmer. Think of how x86-64's 16 architectural registers are dynamically renamed to more than 120 physical registers.

ndesaulniers 11y ago
That certainly is an interesting idea to think about. I would think it's hard to beat the compiler though (when it knows how many GP registers there are). Consider register pressure. If the compiler assumes there are infinite GP registers (because they're hidden now, no longer an implementation detail), it can generate code that spends more time spilling and reloading registers than computing. The compiler has seen the code before; it knows how many variables it will need to work with an how to schedule available resources. The processor (relatively) simply is executing a stream of instructions. It would have to look pretty far ahead (VLIW) or have sufficient execution units (superscalar) to have high throughput and not get bogged down spilling. But, if the finite amount of resources, like number of processing units or GPRs become very high relative to the amount of symbolic variables, then I think the register names could be hidden.
- chrisseaton 11y ago
  > when it knows how many GP registers there are But compilers don't know this! They know how many registers there are in the ISA, but not how many there really are in the physical architecture. Physical architectures map ISA register names into register file locations. It's an abstraction! You can really use a register more than once at the same time because they will be renamed. Your parent is suggesting that we read and write from memory as normal, and just map memory locations into the register file, rather than ISA register names. Registers may be more of an abstraction than you realise. (Maybe compilers do know about how large the register rename buffer really is on certain physical chips and take this into account when allocating them. Sounds like something Intel's C compiler might do. I'm not an expert.)
  - vardump 11y ago
    > You can really use a register more than once at the same time because they will be renamed. What do you mean by this? Do you realize register renaming is only done for instruction scheduling purposes, to avoid bubbles in the pipeline?
    - Someone 11y ago
      I guess he refers to pipelining, which sort-of can give you a logical register twice. For example, you may be able write a new value to a register before the instruction writing out the old value has completed.
      - chrisseaton 11y ago
        Yes. I'm not an architecture expert but I understand that if you do something like: addl %ebx, %eax movl %eax, foo(%rip) addl %ecx, %eax movl %eax, bar(%rip) Then the second add can start while the first and the first mov are still running, because the logical reuse of eax is independent of the first and so will receive a different entry in the rename buffer. Happy to be confirmed or corrected by someone who knows more.
  - marcosdumay 11y ago
    Yes, on AMD64. I'm a big fan of the Mill's idea of a specialized compiler that reencodes a general code into your architecture. It solves this problem, allows for JIT optimization of compiled languages, and is a nice portability layer available for virtualizing other architectures. It also adds a nice layer for malware to hide, but well, we can't have everything.
    - monocasa 11y ago
      You should look at the AS/400. They've actually been shipping a product using this scheme for almost 40 years.

ndesaulniers 11y ago

That certainly is an interesting idea to think about. I would think it's hard to beat the compiler though (when it knows how many GP registers there are). Consider register pressure. If the compiler assumes there are infinite GP registers (because they're hidden now, no longer an implementation detail), it can generate code that spends more time spilling and reloading registers than computing. The compiler has seen the code before; it knows how many variables it will need to work with an how to schedule available resources. The processor (relatively) simply is executing a stream of instructions. It would have to look pretty far ahead (VLIW) or have sufficient execution units (superscalar) to have high throughput and not get bogged down spilling. But, if the finite amount of resources, like number of processing units or GPRs become very high relative to the amount of symbolic variables, then I think the register names could be hidden.

chrisseaton 11y ago
> when it knows how many GP registers there are But compilers don't know this! They know how many registers there are in the ISA, but not how many there really are in the physical architecture. Physical architectures map ISA register names into register file locations. It's an abstraction! You can really use a register more than once at the same time because they will be renamed. Your parent is suggesting that we read and write from memory as normal, and just map memory locations into the register file, rather than ISA register names. Registers may be more of an abstraction than you realise. (Maybe compilers do know about how large the register rename buffer really is on certain physical chips and take this into account when allocating them. Sounds like something Intel's C compiler might do. I'm not an expert.)
- vardump 11y ago
  > You can really use a register more than once at the same time because they will be renamed. What do you mean by this? Do you realize register renaming is only done for instruction scheduling purposes, to avoid bubbles in the pipeline?
  - Someone 11y ago
    I guess he refers to pipelining, which sort-of can give you a logical register twice. For example, you may be able write a new value to a register before the instruction writing out the old value has completed.
    - chrisseaton 11y ago
      Yes. I'm not an architecture expert but I understand that if you do something like: addl %ebx, %eax movl %eax, foo(%rip) addl %ecx, %eax movl %eax, bar(%rip) Then the second add can start while the first and the first mov are still running, because the logical reuse of eax is independent of the first and so will receive a different entry in the rename buffer. Happy to be confirmed or corrected by someone who knows more.
- marcosdumay 11y ago
  Yes, on AMD64. I'm a big fan of the Mill's idea of a specialized compiler that reencodes a general code into your architecture. It solves this problem, allows for JIT optimization of compiled languages, and is a nice portability layer available for virtualizing other architectures. It also adds a nice layer for malware to hide, but well, we can't have everything.
  - monocasa 11y ago
    You should look at the AS/400. They've actually been shipping a product using this scheme for almost 40 years.