Stack vs register args. Re: varargs

[Rex Ballard]

In article <129 at drilex.UUCP> dricej at drilex.UUCP (Craig Jackson) writes:
>
>Microcomputers pass things in registers, rather than on the stack, because 
>stack operations are slow relative to register operations.  This is also
>typical of assembly language programming, rather than C language programming.
>Not everybody is willing to pay the high-level language penalty.

The reason I asked why people use registers rather than a vector (usually
the stack) to pass arguments to the O.S. is because the typical High Level
language interface "glue" is at least as costly as the low level version.

Assuming that the typical "C call" is:
	push arg 1
	push arg 2
	   .
	   .
	call <routine>;
	drop args  ; add constant to sp

For example,

	fd=open(fname,mode);
calls
open(fname,mode)	/* just added the overhead of a frame call */
{
	fd=sys(OPEN,fname,mode);
	return(fd);
}

which calls the assembler routine

sys:	; figure out how many arguments should be put into registers
	; logic to do this (usually a case statement in assembler)
	; has been deleted
sysopn:
	mov 1(sp),r1
	mov 2(sp),r2
	mov 3(sp),r3
	    .
	    .
	    .
	trap
	;result is in r0

the alternative would be
	fd=open(fname,mode);
calls

open(fname,mode);
{
	fd=sys(OPEN,&fname);
}
calls assembler routine -
sys:
	trap SYS ;arguments are already on the stack
		;second argument is the vector pointing to the "real arguments"
	;result is in r0.

even more direct
	fd=open(fname,mode)
calls assembler routine -
open:	; just saved one level of "framing overhead"
	trap OPEN	; works exactly like this if there are enough
			; trap vectors, otherwise would be a push/call macro
	;result is in r0.
	ret

in assembler, since fname and mode are usually constants somewhere,
the "vector" could actually be static memory space.

fname:		db	"file.name"
mode:		dw	2

openargs:	dw	fname
		dw	mode

The assembler routine could call "open" as follows.

		mov	openargs,r0
		push	r0
		trap	OPEN

One of the side benefits is that you have registers available to
traverse the various transforms without corrupting the "frame".