alloca(), #if, and other controversial things...

[Charles Marslett]

In article <1257 at mcgill-vision.UUCP>, mouse at mcgill-vision.UUCP (der Mouse) writes:
> In article <355 at sdrc.UUCP>, scjones at sdrc.UUCP (Larry Jones) writes:
> > Just to confuse the discussion further, what about machines /
> > operating systems which do not have a stack?
> 
> I would expect an implementation of C on such a machine to provide a
> stack, implemented in software to the extent that it isn't supported by
> the hardware.  Not that it must, of course; I can imagine a C compiler
> for a Lisp Machine which doesn't put automatics on the stack.  But I
> would be somewhat surprised to find one that didn't.
> 
Actually I have programmed using two C compilers for the 6502 and one I
consider a REAL TOY (I wish I could emphasize that even more) just because
it did put automatic variables on the stack -- all 256 bytes of it!  The
other had return addresses only on the hardware stack and if I remember
correctly, only put automatic variables on a seperate software stack if
the function was called recursively because of the excessive overhead
involved in copying the entire data area to and from the stack each time
the function was called.  So recursive routines used two stacks, non-
recursive ones used one and in no case were automatic variables actually
used on the stack.

I might also ask, "Do sliding frame RISC machines have any C compilers that
work similarly?"  Or do they shuffle the frame to and from the memory stack
without reference to structure?

> 					der Mouse
> 

                                         a (former) 6502 c programmer
                                         Charles Marslett
                                         chasm at killer.dallas.tx.us