I thought about the stuff in my previous about marking the this pointer as a register. It might go totally wrong in some situation and in some not. I still follow the believe that it's not necessary to think about that if the function will be inlined. If it's so important and performance-critical to have this in a register, you can also inline it. Pushing local variables and parameters on the stack can be far more demanding in terms of instruction count than simply inlining it. On the other side, that's probably simply garbage! CDecl is stack-based, does only reserve the eax register as return value. Therefore, I can't think of any way to explicitely say that this goes into a register. Or well, it probably loads them from the stack to registers, hm... Yeah, that's probably the case. Too bad I'm currently hacking on windows, so there's no way I can test it's output with no effort. However, I'm thinking about introducing a #define-based pseudo thiscall system that should also work for inlining stuff and so on. I know that the crux of inlining is too important too ignore it completely. So, depending on the included files, the library user should decided whether to include the inline or classic function-called files. It would be quite simple in theory. Define a prefix for all functions, put the funcs into a header file and include it in a c file. So depending on the prefix it can either get inlined using the header or will be normally compiled into the C file. Need to test this out one day. However, I'll stick with the inlined header funcs at first. Is just nicer to code using it.