4 ms·

Code density is the biggest one. If I want to add two numbers with a stack design I have an add opcode. If I have 128 instructions that's 6 bits of opcode. I on

Code density is the biggest one. If I want to add two numbers with a stack design I have an add opcode. If I have 128 instructions that's 6 bits of opcode. I only need one because the add opcode will pop the two numbers off the top of the stack and push the result back on. If I want to add two numbers with a register design I need to specify which registers which means if I have 16 registers I need 4 bits per operand minimum which means 12 bits just for the two sources and destinations. If I'm trying to write for an embedded system you can't get higher code densities than using a stack machine. The instructions can also execute faster because I don't have to do things like decode registers and look them up in the register rename table but modern CPUs pipeline this shit so well you never have to worry about instruction latencies. For register based machines one big advantage is that it's way easier for compilers to optimize for register based systems. If I have a common value that I'm using constantly if I was using a stack based arch I'd have to keep pushing that value to the stack. With a register machine I just slap the value in a register and use it as an operand as many times as I need.

retrac 4y ago
> modern CPUs pipeline this shit Quite. In practice, a high-performance processor today, either stack or register, will internally have little resemblance to the presented instruction set. The stack will become a huge array of registers that are the inputs and outputs to various computation units, and they will be tracked and renamed as necessary to align with the various slots in the stack, rather than actually moving things around on the stack. Just as the integer register file on a register machine, becomes a huge array of registers that are renamed as necessary. Any difference between them, in terms of hardware implementation, has largely disappeared over the last couple decades.
- qorrect 4y ago
  Are these mutual exclusive ? Are there any compilers that use both stack and registers ?
  - Taniwha 4y ago
    almost all compilers start using the stack when they run out of registers
agumonkey 4y ago
It's funny because this is the same kind of properties that appealed to me in FP. You compose stuff without having to "encode" parameters. Lighter (unnecessary) information for my brain. And to a point.. pointfree in haskell is an extreme of that, albeit at some point you start having to remember more information if you stack too many operators.

retrac 4y ago

> modern CPUs pipeline this shit Quite. In practice, a high-performance processor today, either stack or register, will internally have little resemblance to the presented instruction set. The stack will become a huge array of registers that are the inputs and outputs to various computation units, and they will be tracked and renamed as necessary to align with the various slots in the stack, rather than actually moving things around on the stack. Just as the integer register file on a register machine, becomes a huge array of registers that are renamed as necessary. Any difference between them, in terms of hardware implementation, has largely disappeared over the last couple decades.

qorrect 4y ago
Are these mutual exclusive ? Are there any compilers that use both stack and registers ?
- Taniwha 4y ago
  almost all compilers start using the stack when they run out of registers

agumonkey 4y ago

It's funny because this is the same kind of properties that appealed to me in FP. You compose stuff without having to "encode" parameters. Lighter (unnecessary) information for my brain. And to a point.. pointfree in haskell is an extreme of that, albeit at some point you start having to remember more information if you stack too many operators.