4 ms·

This is a funny result in the RISC and ARM world, but it makes perfect sense in x86: x86 is a register-memory architecture instead of a load-store architecture,

This is a funny result in the RISC and ARM world, but it makes perfect sense in x86: x86 is a register-memory architecture instead of a load-store architecture, so memory is (effectively) an extremely large register bank.

tenebrisalietum 4y ago
Idk ... this is like saying your local grocery store is effectively your extremely large kitchen, it ignores the logistics and cost of access that create planning or out-of-order requirements for best performance. > so memory is (effectively) an extremely large register bank. This was true-ish however in the late 70's/early 80's/1Mhz CPU days - but registers were always better even if slightly. The 6502, for example, could load the X register with an immediate value in 2 cycles, or from zero page (first 256 bytes of RAM) in 3 cycles, or from an arbitrary 16-bit address in 4 cycles. The few register-to-register operations all work in 2 cycles. (Then you have the TMS9900 that actually did use RAM as registers - only having 3 - one for the program counter, one for the status register, and a "workspace pointer" that told the CPU where the fake 'registers' lived.) Of course, x86 has elaborate caching mechanisms to help. Your freezer is still in your kitchen (cache), but you still have limited space you actually use to do work (countertop). What RAM is basically a superfast I/O device (which is why memory-mapped I/O is a thing). It's funny that the IBM mainframe for RAM - "storage" - kinda made more and more sense the more that RAM speed diverged from CPU speed.
- woodruffw 4y ago
  I meant in the computation-theoretic sense: x86 doesn’t distinguish between types of operands in the way that load-store architectures do, which means that this result (TC without register operands) is not a surprising one. You obviously shouldn’t use RAM as a naive replacement for GPRs in normal code (unless the goal is extremely fast JIT compilation where minimizing spills is not important).
- MobiusHorizons 4y ago
  I believe the parent was talking about the abstraction provided by the ISA, not whether it was a good way to program. None of this experiment cares about the execution speed at all, it merely concerns itself with the technical feasibility of the technique in the ISA. This would not be possible at all in a load store oriented ISA, because you can’t ever do an alu instruction without first loading into a register.
hangonhn 4y ago
This might be a bit of a tangent but what's the advantages and disadvantages of register-memory vs. load-store? Thanks!
- rwaksmunski 4y ago
  I would imagine load-store to be simpler to implement in hardware.
- __s 4y ago
  register-memory will involve a more complicated encoding (to designate addressing modes, tho arguably register/memory is only 1 bit, but that halves your register count for the same size encoding, & it gets messy because your addressing encoding itself will want to reference registers & then you add in offsets/scaling for r1+r2*4) & screws up cycle accurate instruction timing (because memory latency is cache dependent)
- oso2k 4y ago
  RM machines usually have more Memory Modes with which to access memory. You can do a math op while indirectly accessing a memory address that depends on a calculation of that address and add and offset to it. So that makes programming many things easier. It’s a little more how humans learn and think of math. Think using arrays, lists, vectors, hashes, trees. However, this often generates data dependencies which makes pipelining and ILP require more work to achieve efficiently. It also often makes the code dense. https://en.m.wikipedia.org/wiki/Register%E2%80%93memory_architecture https://en.m.wikipedia.org/wiki/Register%E2%80%93memory_arch... LS is generally found in RISC machines and is also generally considered far easier to implement pipelining and ILP. Fewer and often simpler Memory Modes, more obvious or simpler to deduce data dependencies. But it often takes a few more instructions to complete an algorithm or even a simple expression. Less code density. https://en.m.wikipedia.org/wiki/Load%E2%80%93store_architecture https://en.m.wikipedia.org/wiki/Load%E2%80%93store_architect... There’s also stack machines which approximate math well especially if you like RPN/prefix notation. They just tends to make logical constructs like loops look unfamiliar when compared to math or typical/popular programming languages. So it makes programming easy, compiling easy since it’s relatively natural to analyze & compile expressions. Also, instructions can be extremely compact such as single bytes. https://en.m.wikipedia.org/wiki/Stack_machine https://en.m.wikipedia.org/wiki/Stack_machine Another slightly related take was VLIW. You take snippets of instructions (Basic Blocks in PL) that are known to fit certain pipelining or data dependencies rules. Theses blocks of code can then be executed concurrently since you have well established criteria. However making compilers able to predict when blocks should execute in the presence of a complex single processor turned out to make writing the compilers very complex. https://en.m.wikipedia.org/wiki/Very_long_instruction_word https://en.m.wikipedia.org/wiki/Very_long_instruction_word
commandlinefan 4y ago
I can't find the exact quote or attribute it, but a good take was "the x86 instruction set isn't particularly complex - it just doesn't make a lot of sense".

tenebrisalietum 4y ago

Idk ... this is like saying your local grocery store is effectively your extremely large kitchen, it ignores the logistics and cost of access that create planning or out-of-order requirements for best performance. > so memory is (effectively) an extremely large register bank. This was true-ish however in the late 70's/early 80's/1Mhz CPU days - but registers were always better even if slightly. The 6502, for example, could load the X register with an immediate value in 2 cycles, or from zero page (first 256 bytes of RAM) in 3 cycles, or from an arbitrary 16-bit address in 4 cycles. The few register-to-register operations all work in 2 cycles. (Then you have the TMS9900 that actually did use RAM as registers - only having 3 - one for the program counter, one for the status register, and a "workspace pointer" that told the CPU where the fake 'registers' lived.) Of course, x86 has elaborate caching mechanisms to help. Your freezer is still in your kitchen (cache), but you still have limited space you actually use to do work (countertop). What RAM is basically a superfast I/O device (which is why memory-mapped I/O is a thing). It's funny that the IBM mainframe for RAM - "storage" - kinda made more and more sense the more that RAM speed diverged from CPU speed.

woodruffw 4y ago
I meant in the computation-theoretic sense: x86 doesn’t distinguish between types of operands in the way that load-store architectures do, which means that this result (TC without register operands) is not a surprising one. You obviously shouldn’t use RAM as a naive replacement for GPRs in normal code (unless the goal is extremely fast JIT compilation where minimizing spills is not important).
MobiusHorizons 4y ago
I believe the parent was talking about the abstraction provided by the ISA, not whether it was a good way to program. None of this experiment cares about the execution speed at all, it merely concerns itself with the technical feasibility of the technique in the ISA. This would not be possible at all in a load store oriented ISA, because you can’t ever do an alu instruction without first loading into a register.

hangonhn 4y ago

This might be a bit of a tangent but what's the advantages and disadvantages of register-memory vs. load-store? Thanks!

rwaksmunski 4y ago
I would imagine load-store to be simpler to implement in hardware.
__s 4y ago
register-memory will involve a more complicated encoding (to designate addressing modes, tho arguably register/memory is only 1 bit, but that halves your register count for the same size encoding, & it gets messy because your addressing encoding itself will want to reference registers & then you add in offsets/scaling for r1+r2*4) & screws up cycle accurate instruction timing (because memory latency is cache dependent)
oso2k 4y ago
RM machines usually have more Memory Modes with which to access memory. You can do a math op while indirectly accessing a memory address that depends on a calculation of that address and add and offset to it. So that makes programming many things easier. It’s a little more how humans learn and think of math. Think using arrays, lists, vectors, hashes, trees. However, this often generates data dependencies which makes pipelining and ILP require more work to achieve efficiently. It also often makes the code dense. https://en.m.wikipedia.org/wiki/Register%E2%80%93memory_architecture https://en.m.wikipedia.org/wiki/Register%E2%80%93memory_arch... LS is generally found in RISC machines and is also generally considered far easier to implement pipelining and ILP. Fewer and often simpler Memory Modes, more obvious or simpler to deduce data dependencies. But it often takes a few more instructions to complete an algorithm or even a simple expression. Less code density. https://en.m.wikipedia.org/wiki/Load%E2%80%93store_architecture https://en.m.wikipedia.org/wiki/Load%E2%80%93store_architect... There’s also stack machines which approximate math well especially if you like RPN/prefix notation. They just tends to make logical constructs like loops look unfamiliar when compared to math or typical/popular programming languages. So it makes programming easy, compiling easy since it’s relatively natural to analyze & compile expressions. Also, instructions can be extremely compact such as single bytes. https://en.m.wikipedia.org/wiki/Stack_machine https://en.m.wikipedia.org/wiki/Stack_machine Another slightly related take was VLIW. You take snippets of instructions (Basic Blocks in PL) that are known to fit certain pipelining or data dependencies rules. Theses blocks of code can then be executed concurrently since you have well established criteria. However making compilers able to predict when blocks should execute in the presence of a complex single processor turned out to make writing the compilers very complex. https://en.m.wikipedia.org/wiki/Very_long_instruction_word https://en.m.wikipedia.org/wiki/Very_long_instruction_word

commandlinefan 4y ago

I can't find the exact quote or attribute it, but a good take was "the x86 instruction set isn't particularly complex - it just doesn't make a lot of sense".