🚀 go-pugleaf

Thad Smith writes:
|> Konrad Schwarz wrote:
|> >In article <4hqed0$1lc@solutions.solon.com>, kanze@gabi-soft.fr (J. Kanze) writes:
|> >|>     [Concerning alloca...]
|> >I: As far as I know, implementing alloca via the stack is trivial on
|> >I: any general-purpose CPU, but I am interested in hearing of counter examples.
|> >|> 
|> >|> So what do you do on machines that don't have a stack?
|> >
|> >General-purpose CPU's have stacks, at least in my book.  How do you
|> >implement C on machines that don't have a stack?
|> 
|> I am currently using such a beast for embedded firmware development on
|> an Intel 8051, which has a very small stack.  Allocation of auto
|> variables is done in two ways:
|> 
|> 1.  A software stack in external memory is allocated for functions
|> that are explicitly reentrant.  This is the exception because of the
|> overhead required to manage and use the software stack.
|> 
|> 2.  Fixed memory areas are allocated for non-reentrant functions.  The
|> loader generates the calling tree and figures out what functions are
|> never active concurrently.  Those functions can be allocated the same
|> area in memory.
|> 
|> Because the default is non-reentrant and a declaration is required for
|> reentrant functions, it isn't fully conforming.  Also, the linker
|> needs some additional information when function pointers are used to
|> know who calls whom.  In general, it seems to be a good adaptation of
|> C to the limited resources of the target processor.

[getting back to my point:]

Thus, a declaration for functions using alloca would not be out of line.
You could then either implement alloca on your comparatively slow
software stack, or using the even slower malloc/free (assuming you
have that---if not, the whole point is moot).

Konrad Schwarz