News for hackers. Stuff that matters.
Re:Size visualization of Go executables using D3 by userbinator on Tuesday April 02, 2019 @09:45PM (#19560145)
Push and pop aren't that great because they mutate the stack pointer for each value you push or pop instead of mutating it once.

The push and pop instructions are specifically optimised; see the section titled "Stack Engine" here for a brief explanation:

https://en.wikipedia.org/wiki/Stack_register

Not only does using mov with a base+displacement addressing mode not take advantage of the specialised stack hardware and also increases the code size, it also means extra effective-address calculations for the ALU.

If you don't believe that, look at this:

https://lists.llvm.org/pipermail/llvm-dev/2014-December/0799...

When someone who works for Intel proposes changing LLVM to generate push instead of mov for calls, and even suggests push-pop pairs for memory-memory moves to save on register allocation (I've seen this trick before in handwritten Asm, but can't recall if ICC does it too --- it might), I think you had better listen to him, unless you believe it's some sort of a weird conspiracy to make other compilers worse so that Intel's looks better... but then again, ICC and MSVC (among others) use push too, and they're certainly not any slower for it.

Re:Size visualization of Go executables using D3 by pcwalton on Tuesday April 02, 2019 @10:16PM (#19560260)
> If you don't believe that, look at this:

The followups cite Agner's tables to show that push and pop are slower. Reg/mem move has reciprocal throughput 0.5 on Haswell, while pop has 1.

It's a code size win, but not really a speed win.