using an FPGA to emulate a vintage computer
in [FPGA]
|
From: glen herrmannsfeldt on 22 Feb 2010 15:28 In comp.arch.fpga rickman <gnuarm(a)gmail.com> wrote: (big snip) > A hardware stack for C is a bit of a problem. C tends to need a > rather large stack because of the stack frames used. It depends, somewhat, on the programmer. In K&R C, you couldn't pass a struct, but instead a pointer to a struct. That kept the stack a little smaller, at least. With C89, as with K&R, arrays (including automatic, allocated on the stack) had a constant dimension. If I remember right, C99 added the ability to dimension local automatic (stack) arrays with variables. (Previously, a pointer on the stack and malloc() would have been used, along with the requirement to remember free().) > A language like > Forth, on the other hand, can get by with a very small hardware stack > because the stack usage tends to be minimal and subroutine nesting > does not automatically add to the data stack depth. Instead, often > parameters that are passed into one routine are also passed onto the > next without duplication until they are consumed by the calculations > that need them. In c every call copies every piece of data needed for > the lower level code creating stack "bloat" if you will. If you only pass pointers, it isn't so bad... -- glen
From: glen herrmannsfeldt on 22 Feb 2010 17:10 In comp.arch.fpga Eric Chomko <pne.chomko(a)comcast.net> wrote: (snip) > I'm pretty sure ALGOL and PL/I are far worse WRT to stack > bloat than is C. ALGOL, PL/I, and C pretty much require local variables to be automatic. (PL/I procedures without the RECURSIVE attribute might get away with static allocation.) Fortran up through Fortran 77 allowed local variables to be statically allocated. Without the RECURSIVE attribute, it probably still does. Other than passing of arguments, it depends on how you allocate your variables. PL/I has the STATIC attribute which will keep variables off the stack, as does C. Be careful with recursion, though. For ALGOL, maybe you need internal procedures using variables from outside, and to minimize actual local variables. PL/I can easily generate temporary variables, including arrays. > But yes, nothing would beat FORTH unless you used assembly and only > architectures with HW stacks. Two being better than one (i.e. 6809 vs > 6800). -- glen
From: Charles Richmond on 22 Feb 2010 17:29 glen herrmannsfeldt wrote: > In comp.arch.fpga rickman <gnuarm(a)gmail.com> wrote: > (big snip) > >> A hardware stack for C is a bit of a problem. C tends to need a >> rather large stack because of the stack frames used. > > It depends, somewhat, on the programmer. In K&R C, you couldn't > pass a struct, but instead a pointer to a struct. That kept > the stack a little smaller, at least. With C89, as with K&R, > arrays (including automatic, allocated on the stack) had a > constant dimension. If I remember right, C99 added the ability > to dimension local automatic (stack) arrays with variables. > (Previously, a pointer on the stack and malloc() would have > been used, along with the requirement to remember free().) > And even though structs *can* be passed to and returned from functions, a programmer is *not* forced to do that. One can still pass the pointers to structs. One can still use "malloc()" and "free()" to allocate variable-size arrays. If you are an "old time" C programmer, this probably fits better in your way of thinking. In any case, if it is important to conserve stack space, the "good ole ways" can still be used. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+
From: Peter Flass on 22 Feb 2010 17:53 Eric Chomko wrote: > > I'm pretty sure ALGOL and PL/I are far worse WRT to stack bloat than > is C. PL/I can be, but doesn't have to be. If the arguments of a procedure match the parameters, only the argument address (and possibly a descriptor address for strings structures, and arrays) is passed. If the argument doesn't match, the compiler nicely copies it to a "dummy argument" that does. As usual, the programmer needs to have some idea what's going on.
From: Scott Lurndal on 22 Feb 2010 19:02
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> writes: >In comp.arch.fpga rickman <gnuarm(a)gmail.com> wrote: >(big snip) > >> A hardware stack for C is a bit of a problem. C tends to need a >> rather large stack because of the stack frames used. > >It depends, somewhat, on the programmer. In K&R C, you couldn't >pass a struct, but instead a pointer to a struct. That kept >the stack a little smaller, at least. With C89, as with K&R, >arrays (including automatic, allocated on the stack) had a >constant dimension. If I remember right, C99 added the ability >to dimension local automatic (stack) arrays with variables. >(Previously, a pointer on the stack and malloc() would have >been used, along with the requirement to remember free().) Some C implementations supported alloca() which would allocate on the stack (and would be automatically free'd on return). A minimal C stack frame is the return instruction pointer, with arguments passed in registers. scott |