This reads like word games. The article basically argues for optimizing the calling discipline on a per-function basis, using the function body to guide the optimization. That's not a calling convention and definitely not a standard ABI. What they're arguing for is a kind of static optimization mid-way between targeting a calling convention and inlining. That's not a bad idea on its face, but has nothing at all to do with the C ABI. As to whether it would actually improve anything, frankly, I'm half-surprised compilers don't already do this, i.e. for functions where it's deemed too costly to inline, but which aren't externally visible, and the fact that they don't suggests that maybe there's not much to gain here.
I've yet to read an article criticizing the so-called C ABI that doesn't end up effectively changing the problem statement (in this case, into something utterly incomparable), as opposed to providing a better solution to the same problem. Changing the problem statement is often how you arrive at better solutions overall, but don't try to sell it as something it isn't, insinuating that the pre-existing solution is stupid.
Rust already puts a burden on me because of memory-management complexity. I welcome conventions like this when the compiler can hide most of that complexity.
Pre-1.0. Rust removed the green-threads runtime prior to stabilization.
I personally think this was one of the most important changes Rust made; without it, Rust would have been interesting but would not have been able to compete directly with C and C++ for systems programming.
Previously:
The Rust calling convention we deserve - https://news.ycombinator.com/item?id=40081314 - April 2024 (137 comments)
This reads like word games. The article basically argues for optimizing the calling discipline on a per-function basis, using the function body to guide the optimization. That's not a calling convention and definitely not a standard ABI. What they're arguing for is a kind of static optimization mid-way between targeting a calling convention and inlining. That's not a bad idea on its face, but has nothing at all to do with the C ABI. As to whether it would actually improve anything, frankly, I'm half-surprised compilers don't already do this, i.e. for functions where it's deemed too costly to inline, but which aren't externally visible, and the fact that they don't suggests that maybe there's not much to gain here.
I've yet to read an article criticizing the so-called C ABI that doesn't end up effectively changing the problem statement (in this case, into something utterly incomparable), as opposed to providing a better solution to the same problem. Changing the problem statement is often how you arrive at better solutions overall, but don't try to sell it as something it isn't, insinuating that the pre-existing solution is stupid.
Rust already puts a burden on me because of memory-management complexity. I welcome conventions like this when the compiler can hide most of that complexity.
What was the interval of time for Rust having green threads, out of curiosity? How if at all had that affected layout and calling?
Pre-1.0. Rust removed the green-threads runtime prior to stabilization.
I personally think this was one of the most important changes Rust made; without it, Rust would have been interesting but would not have been able to compete directly with C and C++ for systems programming.