Re: [MiNT] Stack restore done by OS

[Vincent Rivière <vincent.riviere@freesbee.fr>]

On 10/10/2010 11:40, Miro Kropacek wrote:
> just curious, to your knowledge, what is the reason behind forcing
> programmer to adjust stack manually after each OS call?

That is the traditional C calling convention, named "cdecl".
Its advantages are simplicity and support for functions with variable 
number of arguments, like printf().

However, the vast majority of functions have a fixed number of 
arguments, so the called function could fix the stack itself.

Removing the arguments from the stack in the called function is not 
easy, because the return address is pushed after them. So rts can't be 
used to return and fix the stack. One could pop the return address to 
a0, fix the stack, then jump to a0. Not very natural.
Such calling convention is called "stdcall", I have never seen it on m68k.

On the other side, the x86 cpus have a nice feature: the assembler ret 
instruction (similar to rts) can take an optional integer argument for 
cleaning the stack after return. So the stdcall calling convention is 
very efficient and simple to implement on these processors. Microsoft 
has used that stdcall calling convention everywhere in the Win32 API: 
the caller pushes the arguments, call a function from a system DLL, and 
that's all. The function has removed its own arguments.

The C compilers on Windows allows to chose the calling convention for 
your own C functions. stdcall can be used for a bit more efficiency. 
However, for the rare functions taking a variable number or arguments, 
cdecl has to be used in any case.

So, in conclusion, I think that Atari had designed the trap interface 
like classic C functions using cdecl. And also, as Andreas said, it 
would have been even more complicated to fix the stack inside the traps 
than in regular functions.

NB: On Atari, if your stack is big enough, you don't have to clean it up 
after each system call. You can make a big cleanup at the end... or never.

--
Vincent Rivière