> what would be the point of a calling convention different to the rest of the system C is actually the exception and not the rule, most languages have differ

> what would be the point of a calling convention different to the rest of the system C is actually the exception and not the rule, most languages have different or multiple calling conventions. > what's the alternative you have in mind when using assembler? Assemblers also have a notion of a stack and non-stack addresses, after all. Growable segmented stacks. Now sure, you can do mostly anything in C. But again, it's not assembly. Is it that odd that someone would want to write a compiler without having to write an x86 code generator, or tying themselves to C which again, cannot implement certain things at all? > you can emit calls to the platform's thread primitives (CreateThreadEx, pthread_create, etc) pthread_create is not a platform primitive, it's a glibc function, and interestingly cannot be written in C. > What feature do you have in mind that cannot be implemented by emitting C You can't implement fibers with growable stacks in C. Now you can use <ucontext.h> (getcontext, setcontext, swapcontext are all libc functions implemented in assembly) but they are very expensive with low hanging fruit for optimizations (for example, not saving the fp status registers or signal mask). Context switching also depends on your calling convention, so you may want to have multiple variants that are emitted for different parts of the program, or evolve over time. For growable stacks you need to insert a prologue into function signatures to check if the stack needs to grow, however you probably don't want to do this for every function call and can write peephole optimizations in your compiler to avoid doing it. There are other problems with C that aren't even worth mentioning, notably the linkage/loading model.