Live data from Hacker News

Don't Clobber the Frame Pointer

nsrip.com

21–30 of 46 posts

Re: Don't Clobber the Frame Pointer

#21

Speaking as an Asm programmer for several decades: Calling conventions are stupid. They are the results of mindless stupid-compiler-oriented thinking from a time when compilers produced horrible copy-paste-replace code. The CPU itself couldn't care less which registers you use for what. So many wasted bytes on moving values between registers, just because the calling convention wanted it there, and no other reason. T…

do people think this is insightful? do you?

> conventions are stupid

all conventions are stupid when examined through the lens of an isolated island dweller. you might as well be saying something like "you only need to drive on the left-hand side of the road when you're driving on public roads".

Re: Don't Clobber the Frame Pointer

#22

Speaking as an Asm programmer for several decades: Calling conventions are stupid. They are the results of mindless stupid-compiler-oriented thinking from a time when compilers produced horrible copy-paste-replace code. The CPU itself couldn't care less which registers you use for what. So many wasted bytes on moving values between registers, just because the calling convention wanted it there, and no other reason. T…

do people think this is insightful? do you? > conventions are stupid all conventions are stupid when examined through the lens of an isolated island dweller. you might as well be saying something like "you only need to drive on the left-hand side of the road when you're driving on public roads".

Compilers were stupid, and that's how we ended up with this constant overhead of inefficiency long after they could've done better; it's only within the last decade or so that "custom calling conventions" started being even considered.

Re: Don't Clobber the Frame Pointer

#23

Earlier quoted context omitted.

do people think this is insightful? do you? > conventions are stupid all conventions are stupid when examined through the lens of an isolated island dweller. you might as well be saying something like "you only need to drive on the left-hand side of the road when you're driving on public roads".

Compilers were stupid, and that's how we ended up with this constant overhead of inefficiency long after they could've done better; it's only within the last decade or so that "custom calling conventions" started being even considered.

Calling conventions have no more to do with dumb or smart compilers than driving on the left-hand side of the road has to do with dumb or smart urban planners.

Re: Don't Clobber the Frame Pointer

#24
post #19

Speaking as an Asm programmer for several decades: Calling conventions are stupid. They are the results of mindless stupid-compiler-oriented thinking from a time when compilers produced horrible copy-paste-replace code. The CPU itself couldn't care less which registers you use for what. So many wasted bytes on moving values between registers, just because the calling convention wanted it there, and no other reason. T…

> The only need to pay attention to calling conventions is when you're interfacing with compiler-generated code. So, the vast majority of code out there in the wild?

I mean it only matters at the interface.

Re: Don't Clobber the Frame Pointer

#25
post #19

Earlier quoted context omitted.

> The only need to pay attention to calling conventions is when you're interfacing with compiler-generated code. So, the vast majority of code out there in the wild?

vast majority doesn't even begin to describe it - i would wager 10 years of my salary that the fraction of all currently running CPU instructions that were handwritten is so small that it's within the margin of error (i.e., random bit flips) for whatever computer you use to perform the count.

Depending on how you count, the ratio might not be that small. A lot of hot code are written in hand-coded inline assembly, so in terms of CPU cycles run it's probably non-negligible.

i.e. take a look at the glibc implementation of 'strcmp` [0]

[0] https://github.com/bminor/glibc/blob/master/sysdeps/x86_64/m...

Re: Don't Clobber the Frame Pointer

#26

Earlier quoted context omitted.

vast majority doesn't even begin to describe it - i would wager 10 years of my salary that the fraction of all currently running CPU instructions that were handwritten is so small that it's within the margin of error (i.e., random bit flips) for whatever computer you use to perform the count.

Depending on how you count, the ratio might not be that small. A lot of hot code are written in hand-coded inline assembly, so in terms of CPU cycles run it's probably non-negligible. i.e. take a look at the glibc implementation of 'strcmp` [0] [0] https://github.com/bminor/glibc/blob/master/sysdeps/x86_64/m...

> A lot of hot code are written in hand-coded inline assembly

I know... I write GPU assembly for a living... And still I make that wager. It's not a lot. It's not even a little. It's an epsilon (overall). And it gets smaller over time.

Re: Don't Clobber the Frame Pointer

#27

Earlier quoted context omitted.

Compilers were stupid, and that's how we ended up with this constant overhead of inefficiency long after they could've done better; it's only within the last decade or so that "custom calling conventions" started being even considered.

Calling conventions have no more to do with dumb or smart compilers than driving on the left-hand side of the road has to do with dumb or smart urban planners.

Of course they do. An Asm programmer will naturally use the appropriate registers to minimise data movement (see also: PC BIOS interface - no stupid stack shit) depending on the circumstances, a stupid compiler will just push everything on the stack. A more intelligent compiler will behave more like the human programmer and decide how to pass parameters and save or restore registers on a case-by-case basis.

Re: Don't Clobber the Frame Pointer

#28

Earlier quoted context omitted.

Calling conventions have no more to do with dumb or smart compilers than driving on the left-hand side of the road has to do with dumb or smart urban planners.

Of course they do. An Asm programmer will naturally use the appropriate registers to minimise data movement (see also: PC BIOS interface - no stupid stack shit) depending on the circumstances, a stupid compiler will just push everything on the stack. A more intelligent compiler will behave more like the human programmer and decide how to pass parameters and save or restore registers on a case-by-case basis.

[flagged]

Re: Don't Clobber the Frame Pointer

#29
post #10

Earlier quoted context omitted.

>soup to nuts compiler Any chance you can explain that to rubes like me?

Go isn't built on an existing compiler framework like LLVM. It does its own code generation, has its own assembler.

There is an accident of history here. Go was developed with the plan 9 C compiler suite as a starting point. Most notably those compilers did not generate assembler -- they emitted object code directly. This is described here: https://9p.io/sys/doc/compiler.html. The assembler facilitated transforming hand-written assembly to object code. And here the plan 9 folks chose a new syntax, probably because it was simpler to start afresh over using the existing "AT&T" or "Intel" syntax.

Re: Don't Clobber the Frame Pointer

#30

Speaking as an Asm programmer for several decades: Calling conventions are stupid. They are the results of mindless stupid-compiler-oriented thinking from a time when compilers produced horrible copy-paste-replace code. The CPU itself couldn't care less which registers you use for what. So many wasted bytes on moving values between registers, just because the calling convention wanted it there, and no other reason. T…

> The CPU itself couldn't care less which registers you use for what.

Not all registers encode as operands equivalently (implicit rdx:rax, implicit [rbx+al], limited [rbp/r13+imm8]). Some have other encoding restrictions or special purposes (rdi, rsi, rcx). When segmentation was a thing there were different default segments for each. Some are destroyed when certain opcodes used (syscall: rcx, r11).

> So many wasted bytes on moving values between registers [...] Modern CPUs are fast

Well, they've special cased this anyways, as these will often be caught in the rename stage and not even occupy an execution slot. Since we've long recognized that passing these values in registers instead of the stack is far more efficient, which is why the `fastcall` convention came about and got it's name way back in the x86 days.

> but there's still tons of inefficiency in compiler output.

Which is also why the 'inline' heuristic exists. In which case all of the calling conventions are fully abandoned. I mean, things like ELF dynamic symbol tables, and linux thread local storage annoy me far more than calling conventions ever have.

Post reply on HN