Path: utzoo!attcan!uunet!samsung!umich!sharkey!cfctech!ttardis!rlw
From: rlw@ttardis.UUCP (Ron Wilson)
Newsgroups: comp.sys.apple
Subject: Re: ORCA/C problems
Message-ID: <2462@ttardis.UUCP>
Date: 8 Feb 90 18:08:34 GMT
Organization: Gallifrey
Lines: 77

In article <1990Feb7.171108.553@ncsuvx.ncsu.edu>, rnf@shumv1.uucp (Rick Fincher) writes:
>
>In article <1990Feb7.034310.5315@ux1.cso.uiuc.edu> jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) writes:
>>I just got ORCA/C in the mail and am having a problem with it.  The code
>>ran fine under APW so I'm thinking it's a compiler bug.  The code in
>>question leaves excess values on the stack, evidently, and crashes upon
>>return.  Anyone know of any bugs in ORCA that would do this? (I'm sending
>>my registration card in tomorrow, Byteworks said they had beta versions
>>with bug fixes.).
>
>It's not really a bug.  What usually happens is that functions are not
>properly typed so the calling routine pulls the incorrect number of
>parameters off the stack.  This works in APW because the compiler does
>stack repair in cases of bad code like this.  The example in the docs
>of the beta upgrade compiler is:
>
>printf("%ld", 2);  /* This is ILLEGAL */
>
>This doesn't work because printf is expecting a long and gets an int.
>Four bytes are pulled off the stack when only 2 were pushed.
>
>You can send a note to the Byte Works when you send in your warranty card or
>call them and they will send you a beta version of the new compiler that
>will generate stack repair code (at the cost of speed).  It is best to get 
>that stuff out of your code and compile without this option, then you get 
>the best speed.  If you are on America Online send Mike Westerfield a note
>
>Rick Fincher
>rnf@shumv1.ncsu.edu

This so-called stack repair should NOT reduce performance - if it doess, then
the compiler writer(s) are to blame.

So far every C compiler I have used performed function calls in the following
way:

	save current stack pointer to a register
	push parameters onto the stack in reverse order
	push saved stack pointer onto the stack
	call the function via JSR (or equiv - this leaves the return
		address on the top of the stack

	when the function returns, pop the saved stack pointer off the stack
		and set the set pointer to this value

In the called function:

	save current stack pointer as a context reference
	access the passed parameters by using an offset relative to the context
		reference  (this might be a LDA X,4 to access a parameter that
		is 4 bytes deep into the stack - for example)

	when returning, either save the return value in a register, or in a
		location relative to the context reference, then simply
		return using a RTS (or equiv)

The called function does NOT attempt to remove the parameters from the stack -
this task is left to the calling function - thus, this isn't so much a "repair"
of the stack pointer - just normal house keeping - it would ONLY be a repair IF
the called function ALSO (tried to) remove the parameters from the stack.

This is a method I first learned about in collage when I took a compilers
class - I have also seen this method used in Pascal, Modula, Ada, and Fortran
compilers - it is also highly recommended by several books on the subject that
I have seen (I have one at home, I can post the name tomorrow) - and it also
appears in several books on assembly language programming.

I do not think that the ANSI standard requires any peticular method of
implementing function calls - it just highly discourages the "traditional"
C method of writing functions to be called with varying numbers of parameters.

For the machines I work with (or at least have worked with), I can't think of
any better method of passing parameters in a way that allows the called
function to be reentrant or recursive - even on a CPU that uses multiple
banks of on-chip registers to allow parameter pasing without memory copying -
you have a limitted number of registers to use, so you have to resort to
using main RAM for long parameter lists; thus this stack idea still applies.