🚀 go-pugleaf

In article <1992Nov12.094835.8563@wraxall.inmos.co.uk> Geoff Barrett,
geoffb@inmos.co.uk writes:
>More seriously, it does illustrate an important property of occam
>processes, namely that their workspace requirements can be determined
>statically.  If you can't do this, then the implementation of parallel
>processes becomes much more difficult. In current implementations of
>occam, it is possible to allocate a fixed amount of workspace for each
>parallel process.  If you allow recursive processes you cannot
>determine statically how much workspace each process will need.  This
>means that you have to know what to do with stack overflow when the
>obvious place to extend it has been allocated to something else
>already.

Sofar, I agree.

>If you think you have a solution to this, and it does not
>have an adverse affect on the context switch time, then I will be
>interested to hear it.

I am confused. What do you mean when you talk about a 'context
switch'? It is clear that recursion implies additional overheads
at runtime during function calls. That it affects the time to
timeslice processes is totally new to me. Perhaps I am missing
a point here.

>In general, it is more important for an
>embedded application to be sure of enough space in which to run.  After
>all, you don't want to run out of memory just as you reach a critical
>section of control code.

Yes, but knowing how much stack space the embedded application needs
is no reason to rule out the possibility to use recursion in some
language:
If you don't need it, don't use it.

Marco Kesseler

Faculty of Mathematics and Computer Science
University of Nijmegen
Toernooiveld 1
6525 ED Nijmegen
The Netherlands

marcok@cs.kun.nl