Hacker News new | ask | show | jobs
by lmz 527 days ago
> 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?

3 comments

If you're not interfacing with it, say linking it as a library, then it doesn't matter what you do.
Sure, but this sort of limits the kinds of thing you can realistically build unless you want to build everything from the ground up. Even in the case of code reuse with statically linked assembly files there would be some sort of "convention" about how to call and be called.
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...

Now how much of that doesn't interface with compiler generated code?
> 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.

What do you think the percentage of computation is with respect to hand-written vs compiler generated?

If small hot loops tend to be disproportionately hand written, and certain programs spend the majority of time in their hot loops, that could still be a decent percentage of time/instructions executed.

I mean it only matters at the interface.