16032 calling sequences

[mann%Shasta%su-score at sri-unix.UUCP]

From:  Tim Mann <mann%Shasta at su-score>

One of the other people in the research group I work in here
at Stanford is currently porting a message-based operating
system kernel written in C (a Thoth descendent) from the 68000
to a Vax 750.  Sending a message takes 25% longer on the Vax
than on an 8 MHz 68000 (and our newer 68000 machines run at 10
MHz).  The main reason for the slowdown is the slow function
call instruction on the Vax.  The Vax can add faster that the
68000, but context switching is a little slower, and function
calls are much slower.  It sounds like your situation with the
16032 is similar to ours with the Vax, except that in your 
case you still have a choice, while we are more or less stuck
with the existing Berkeley C compiler.

I think in general, with modern processors that don't have
address space limitations, speed is much more important than
size.  Memory is cheap and getting cheaper.  Unfortunately
(depending on your goals in developing this compiler),
compatibility with the rest of the world may be more important
than either.  I suggest, as long as you aren't developing
the compiler for commercial use, that it would be best to 
leave the option in the compiler to use cxp, but make jsr the
default and compile all your standard libraries with it.  If
you ever sell or give the compiler to anyone else, they can
reset the option if it's important to them, or you can reset
it if you ever need to interface with other languages that use
cxp in their compilers.

	--Tim