OSDev.org

Hi everyone,

I'm new around here and have what might be a RTFM question. (The only problem is that I have had a hard time finding manuals or posts for this sort of thing.) I'm starting to write my own OS and would like to use C as the main language. However, I would like to define and use my own ABI. (I'm a bit of a rebel and would prefer to use something other than the standard ABIs, such as System V. I want my OS to be different than the mainstream ones.) How difficult is it to define an ABI for a C compiler (say, gcc)? If it is possible, do you know of any good tutorials on this subject?

Thank you for your time.

Regards,
flippedbits

If you are using GCC it is quite easy. In fact you just use these flags when compiling your code: That will disable everything. You can not include <stdlib.h> or any other. You have to create everything yourself. That is what I do, but I have included PDCLib in my project for a minimal set of standards compliant C libraries.

To do the same in C++ you can use the following flags: I hope that helps.

Oh, I understand that I have to disable built-in functions and not use standard libraries. What I meant by defining a new ABI was creating an assembly-level standard (e.g., which registers hold arguments during function calls, which register holds a function's return value, where extra arguments are stored in memory [e.g., on the stack], and which registers are not for general use [e.g., special purpose registers, such as a register that always holds the current thread ID]). I know that AMD/Intel define standards regarding special purpose registers, but I don't know if they provide more freedom regarding which registers are used for parameter passing and return values. (I know that some architectures, such as SPARC, explicitly denote groups of registers as input, output, and local registers. I don't know if AMD/Intel do the same with their general-purpose registers.)

flippedbits wrote:What I meant by defining a new ABI was creating an assembly-level standard

Ah, now I get it. I'm sorry I don't have an answer for that. I assume that things are pretty hard coded in the GCC backend, so maybe you can try to make a checkout of the GCC sources and have a look in there. As far as I know GCC has a few built-in calling conventions, but it sounds like you want to do something completely new. Another thing is that x86 only have a small number of general purpose registers, so it might be difficult to make a smarter ABI than what already exists. But for the fun of it, why not.

Actually, it's usually up to the compiler to handle such things --- registers are merely a matter of optimizing code; instead of using the stack all the time, you use the registers, which are faster. Application A doesn't have to be like B, it can use the registers in its own way. As an aside, there are a few standard calling conventions (cdecl, stdcall, pascal, etc.) so that applications can be made compatible with the operating system and with each other. These decide things like the ordering of arguments on the stack and if it's up to the caller or callee to free the stack.

Yes, as Love4Boobies says -- if you don't like your compiler's default handling of registers and/or the stack -- then you either have to code in ASM, or you have to rewrite part of your compiler. If you choose the second option, then you will have to specify a precise compiler for us. Even then, we probably will not know how to modify it.

I understood everything that you said. I found AMD's x86-64 ABI specification, located at http://www.x86-64.org/documentation/, and it turns out that it lays down general guidelines about register and stack usage as well as status register states when threads start. True, you have tremendous freedom within a program to use registers however you want, but I want to use a single, general standard for [most of] my OS's functions.

I also compiled a few x86-64 test programs with gcc and it appears that gcc follows the x86-64 ABI guidelines. (Though I have seen a few complaints/bug reports online that gcc doesn't follow it to the letter in certain small respects. No biggie.) So using gcc shouldn't be much of a problem after all. (Porting GCC to my new OS should be interesting.

Thanks for all of your help.

flippedbits