
Exploring calling conventions with x86 assembly (2016) - ingve
https://apoorvaj.io/exploring-calling-conventions/
======
saagarjha
Wikipedia also has a nice page with an overview of most of the common calling
conventions:
[https://en.wikipedia.org/wiki/X86_calling_conventions](https://en.wikipedia.org/wiki/X86_calling_conventions)

------
nneonneo
This is also compiled without optimizations which makes fastcall look less
efficient. In practice fastcall is usually much leaner when you’re not having
to store the arguments to the stack.

~~~
perl4ever
Thinking of all the arguments about "undefined" behavior and optimizations in
C compilers, is it practical these days to do optimizations _only_ at the
assembler level and not at the C source level, in order to avoid unexpected
behavior?

~~~
MaxBarraclough
I don't get your question. If you're writing assembly code, the rules of C
aren't relevant, and of course you're free to do and kind of hand-
optimisation. The downsides are the same as ever: assembly isn't easy to work
with, it's as unsafe as a language can get, and it isn't portable.

If you want to be free of the pitfalls of undefined behaviour, there are
languages other than C that you might consider. Rust, Ada, etc. When compiling
with optimisation, performance should be close to that of C.

I believe both these languages may have dark corners where you may see
implementation-defined behaviour or even something akin to undefined
behaviour, but there's nowhere near as much as in C, where you're constantly
on a knife-edge.

If you want rock solid guarantees, you may be on the path to languages like
SPARK [0] and the upcoming ZZ language [1] [2]. But perhaps I'm digressing.

[0]
[https://en.wikipedia.org/wiki/SPARK_(programming_language)](https://en.wikipedia.org/wiki/SPARK_\(programming_language\))

[1] [https://github.com/aep/zz](https://github.com/aep/zz)

[2]
[https://news.ycombinator.com/item?id=22245409](https://news.ycombinator.com/item?id=22245409)

~~~
perl4ever
I was basically asking if the options on gcc or whatever allow you to turn on
only optimizations at the assembly language level of abstraction. Which it
seems to me would be a practical way to avoid the sort of optimizations that
surprise people while not emitting totally unoptimized code. Maybe that's -O1
or -O2, I don't remember because it's been a long time.

~~~
MaxBarraclough
Perhaps you could set flags to disable all optimisations except the ones you
specifically enable.

Unless the compiler promises to handle the various forms of undefined
behaviour in specific 'safe' ways, this approach isn't going to be robust. GCC
doesn't offer a way to safely handle _all_ instances of UB. That would be a
significant undertaking.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=12421054](https://news.ycombinator.com/item?id=12421054)

------
AshamedCaptain
It's always strange to find Windows guys using the GAS syntax. At the same
time, it's strange to find Unix-y guys using the Intel syntax... (e.g.
godbolt).

