varargs

[grr at cbmvax]

In article <792 at ccird2.UUCP> rb at ccird2.UUCP (Rex Ballard) writes:
>In article <5302 at alice.uUCp> ark at alice.UucP (Andrew Koenig) writes:
>>> I have always heard that varargs is not very portable...
...
>I have heard that there are a few "peculiar"
>compilers available for the Atari ST, Mac, and Amiga, which, although
>not "kosher", CAN support most varargs situations.  The problems that
>can occur are "intelligent" compilers which put arguments directly
>into registers rather than on the stack.  Appearantly, this can be
>a real problem if you wish to "intercept" a system call at the
>application side.  Why do so many of the micro operating systems
>insist on putting arguments in registers!!!.  Even MS-DOS expects
>arguments in registers rather than on the stack.

Mainly cause it makes calling subroutines very fast! (and breaks a lot of code)

imagine:	routine(arg);
		register char *arg;
		{...}

If the compiler knows that arg just happens to be in a suitable register when
the routine is called; the only overhead is an optional register to register
move, and a call instruction.  This can really speed things up when you have a
lot of little inner routines.

However, spare us compiler writers!  It just isn't worth it when you're trying
to use somebody else's 'portable' code.  It would be fine if C had nested
procedures or inlines or something, but a disaster otherwise.

>
>The C frame is a more sensible archetecture...
>

Most micro operating systems, includeing MSDOS include some degree of conceptual
compatibility with CP/M, and the CP/M system system calls were intended to be
used from assembly language programs, thus getting the arguments in registers
was easier than not.  Kind of like the influence the PDP-9 assembler had on the
selection of * and & for the C address operators, when @ and # make a lot more
sense to anybody brought up on a PDP-11.
-- 
George Robbins - now working with,	uucp: {ihnp4|seismo|caip}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr at seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)