Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!genrad!mit-eddi!mit-vax!eagle!harpo!seismo!hao!hplabs!sri-unix!mann%Shasta@su-score From: mann%Shasta%su-score@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: 16032 calling sequences Message-ID: <2049@sri-arpa.UUCP> Date: Fri, 10-Jun-83 13:36:00 EDT Article-I.D.: sri-arpa.2049 Posted: Fri Jun 10 13:36:00 1983 Date-Received: Sun, 12-Jun-83 22:08:56 EDT Lines: 30 From: Tim MannOne 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