Hacker News Reader

Comment by woodruffw | Hacker News Reader

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.

View on HN

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.

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).

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.

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".

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

I would imagine load-store to be simpler to implement in hardware.

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)

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_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_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

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

Aside, if you've had an interest in the Itanium processor, and the very long instruction word sound familiar, that's because it's one of the most famous, widely used example.

If memory serves, the compilers never really caught on. The assumption was that they would eventually figure out how to leverage the explicit parallelism efficiently, but it never materialized as a performant solution for most problems.

In principle, load-store architectures are simpler to implement, simpler to write compilers for, simpler to write speculative optimizations for, and have denser/simpler instruction encodings. Similarly in principle, register-memory architectures are simpler to write assembly for as a human, and simpler to write different speculative optimizations for.

Reply on news.ycombinator.com