3 ms·

As someone deep in an embedded cave, that's illuminating. You have a completely different meaning abstracted on top of the word "register". Over here, in AVR a

As someone deep in an embedded cave, that's illuminating. You have a completely different meaning abstracted on top of the word "register". Over here, in AVR and MSP430 and Cortex-M0 land, there are about 16 registers, instructions take at most 2 registers, and write to the destination (often also a source argument, ADD R1 R2 does R1 := R1 + R2). There is no 'frontend', no renaming, no aliasing, no garbage collector; what you see is what you get. I assume that sometime long ago, the words had the original meaning, but they gradually added abstractions that were still mostly indiscernible at each step of the journey until they had completely diverged.

mystified5016 2y ago
Yeah I'm deep into AVR, never got into the fancy architectures like x86 and this sounded bananas to me. In my world a register is a register is hardware. Hell, by sidestepping GCC's register allocation one can substantially increase performance if you arrange your data into registers that your ALU or other peripheral likes best. Prime example, RAM access can be twice as fast if you load your target address into the X/Y/Z register with LD instead of letting GCC emit the LDS instruction. You'd do something like store a pointer to a very important struct that you want to access many times very quickly. I honestly have no clue if a similar concept exists on modern x86. I'd assume that you are explicitly meant to not care about things at this level and it's all handled behind the scenes. It's crazy how much the x86 CPU does for you, but I find it much more fun to tweak things close to the bare metal.
- gpderetta 2y ago
  It is not really my speciality, but there are equivalent things on OoO Land. Although CPUs are very good at running reasonable code efficiency, peak FP performance is still the real of hand written ASM or at the very least copious use of intrinsics. It can also be very microarchitecture specific. Because FP code often need significant unrolling, the number of architectural registers needed to store partial results can be a bottleneck, especially if the compiler doesn't do a perfect job.
- dzaima 2y ago
  All registers are basically always treated the exact same in OoO-land (though on x86-64 for some instruction forms it can add an extra byte of instruction encoding if there's some operand in r8..r15). But there's still a massive amount of performance tuning. Some fun examples being how Haswell can only do one FP add per cycle, but two FMAs, so you can sometimes improve throughput by replacing some 'a+b's with 'a*1+b' (at the cost of higher latency). Or how, on older Intel, three-addend 'lea' can execute on only one port (as opposed to two for two-addend 'lea', or 3 or 4 for 'add') and has 3-cycle latency (vs. 1 cycle for two-addend; so two back-to-back 'lea's have lower latency than one three-addend one), but still uses only one port and thus can sometimes be better for throughput.
Neywiny 2y ago
While I share your passion, there's still a front end. The front end vs back end of a cpu core exists as long as the logic for decoding an instruction is separate from that of executing. In an AVR core, the "instruction decode" and "instruction register" blocks are the front end, and the ALU is the backend. The first image result for "msp430 cpu core block diagram" for me was [1] which has the first block saying "front end". So like I get it but just because we work on the smallest cores doesn't mean they're alien tech compared to the newest Neoverse or AVX-512 monsters. https://www.researchgate.net/profile/Ch-Srinivas/publication/346975203/figure/fig5/AS:968568296439810@1607936085154/MSP430-core-block-diagram-4.jpg https://www.researchgate.net/profile/Ch-Srinivas/publication...
ip26 2y ago
x86 is the same way for programmers. All the renaming and so forth is completely hidden from the program. It is only detectable through performance differences.
Tuna-Fish 2y ago
The different meaning is for the word "register name", which is a completely separate, reified concept different from "register". The big difference is that RAX or R1 no longer refers to a register, but a register name. Registers are still registers.

mystified5016 2y ago

Yeah I'm deep into AVR, never got into the fancy architectures like x86 and this sounded bananas to me. In my world a register is a register is hardware. Hell, by sidestepping GCC's register allocation one can substantially increase performance if you arrange your data into registers that your ALU or other peripheral likes best. Prime example, RAM access can be twice as fast if you load your target address into the X/Y/Z register with LD instead of letting GCC emit the LDS instruction. You'd do something like store a pointer to a very important struct that you want to access many times very quickly. I honestly have no clue if a similar concept exists on modern x86. I'd assume that you are explicitly meant to not care about things at this level and it's all handled behind the scenes. It's crazy how much the x86 CPU does for you, but I find it much more fun to tweak things close to the bare metal.

gpderetta 2y ago
It is not really my speciality, but there are equivalent things on OoO Land. Although CPUs are very good at running reasonable code efficiency, peak FP performance is still the real of hand written ASM or at the very least copious use of intrinsics. It can also be very microarchitecture specific. Because FP code often need significant unrolling, the number of architectural registers needed to store partial results can be a bottleneck, especially if the compiler doesn't do a perfect job.
dzaima 2y ago
All registers are basically always treated the exact same in OoO-land (though on x86-64 for some instruction forms it can add an extra byte of instruction encoding if there's some operand in r8..r15). But there's still a massive amount of performance tuning. Some fun examples being how Haswell can only do one FP add per cycle, but two FMAs, so you can sometimes improve throughput by replacing some 'a+b's with 'a*1+b' (at the cost of higher latency). Or how, on older Intel, three-addend 'lea' can execute on only one port (as opposed to two for two-addend 'lea', or 3 or 4 for 'add') and has 3-cycle latency (vs. 1 cycle for two-addend; so two back-to-back 'lea's have lower latency than one three-addend one), but still uses only one port and thus can sometimes be better for throughput.

Neywiny 2y ago

While I share your passion, there's still a front end. The front end vs back end of a cpu core exists as long as the logic for decoding an instruction is separate from that of executing. In an AVR core, the "instruction decode" and "instruction register" blocks are the front end, and the ALU is the backend. The first image result for "msp430 cpu core block diagram" for me was [1] which has the first block saying "front end". So like I get it but just because we work on the smallest cores doesn't mean they're alien tech compared to the newest Neoverse or AVX-512 monsters. https://www.researchgate.net/profile/Ch-Srinivas/publication/346975203/figure/fig5/AS:968568296439810@1607936085154/MSP430-core-block-diagram-4.jpg https://www.researchgate.net/profile/Ch-Srinivas/publication...

ip26 2y ago

x86 is the same way for programmers. All the renaming and so forth is completely hidden from the program. It is only detectable through performance differences.

Tuna-Fish 2y ago

The different meaning is for the word "register name", which is a completely separate, reified concept different from "register". The big difference is that RAX or R1 no longer refers to a register, but a register name. Registers are still registers.