Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Exploring calling conventions with x86 assembly (2016) (apoorvaj.io)
44 points by ingve on March 19, 2020 | hide | past | favorite | 8 comments



Wikipedia also has a nice page with an overview of most of the common calling conventions: https://en.wikipedia.org/wiki/X86_calling_conventions


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.


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?


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)

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

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


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.


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.



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).




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: