Thread View: comp.sys.transputer
2 messages
2 total messages
Started by Oyvind Teig
Mon, 23 Nov 1992 10:23
occam and recursion and out-of-memory problems
Author: Oyvind Teig
Date: Mon, 23 Nov 1992 10:23
Date: Mon, 23 Nov 1992 10:23
41 lines
2168 bytes
2168 bytes
Recursion of occam-2 or -3
Rob Kurver writes as a reply to my post:
>>I have seen enough of stack overflow errors to appreciate the lack
-------------------->>
>>of recursion in occam.
>
>Recursion + stack-checking -> no stack overflow.
>
>>This comes close to the discussion of exception-handling: how do
>>you solve that in Pact-C, and what would you recommend when stack overflow
>>is encountered?
>
>Upon stack overflow, the stack is extended by allocating a new block of
>memory from the heap. If this is not possible (out of memory), you get
>a fatal error message and your program aborts.
>>---------------
Ok, you have an interesting solution there, of course you do not remove
the out of memory error (which is what I was thinking about).
Occam does NOT have out-of-memory errors!
-----------------------------------------
Why couldn't you buy the occam sources from Inmos and add your own
experience and make an occam dialect (that allows recursion etc.) ?
After all - occam has not been standardized.
Sure occam isn't C, but C isn't occam either! And you may have adopted
a few of the good things from occam into your C - but you have not made
occam out of it. After all, the security of occam could be
a point to sell?? The lack of pointers, the abbreviations, the retyping,
the othogonality of functions and procedures, the aliasing checks,
the indenting (yes), the protocol with its associated checks, the no-out-
of-memory insurance and least but not last - IT IS MUCH EASIER THAN C.
It is probably too easy for C programmers - who actually would like to
have structured assembler!
But YOU could add your own compiler directives to squeeze it a little!
0yvind Teig
Autronica, Trondheim, Norway
Re: occam and recursion and out-of-memory problems
Author: Rob Kurver
Date: Mon, 23 Nov 1992 15:26
Date: Mon, 23 Nov 1992 15:26
75 lines
3978 bytes
3978 bytes
In <143@autro1.UUCP> teig@autro1.UUCP (Oyvind Teig) writes:
>>Upon stack overflow, the stack is extended by allocating a new block of
>>memory from the heap. If this is not possible (out of memory), you get
>>a fatal error message and your program aborts.
> >>---------------
>Ok, you have an interesting solution there, of course you do not remove
>the out of memory error (which is what I was thinking about).
Correct. The out of memory problem can only be solved by not running
out of memory. So either the development system should not support
any dynamic memory (a rather Orwellian approach), or the user should
be careful about using dynamic memory. If the development system
supports dynamic memory, he can still _choose_ not to use it if he
thinks that's a good idea!!
>Occam does NOT have out-of-memory errors!
Occam does not have dynamic memory support, so can not run out of
memory at run-time. It is still possible, though, to fake dynamic
memory - and apparently there are quite a few people who feel the
need to do this (perhaps just because they don't want to go back to
the days of `fatal error - xxx table overflow' messages). When
dynamic memory is faked, the program can have out of memory errors.
Similarly, if the development system supports dynamic memory but
the program doesn't use it, the program will not suffer from out
of memory errors.
It's not the language feature but the programming construct that
determines whether out of memory errors may occur or not. Apparently,
dynamic memory is useful in quite a few situations. In these
situations, having to build your own dynamic memory support does
not improve security.
>Sure occam isn't C, but C isn't occam either! And you may have adopted
>a few of the good things from occam into your C - but you have not made
>occam out of it.
No, we have not made occam out of it, nor did we want to. Many people
_like_ recursion, pointers, data structures, etc. They like being able
to take their existing code and run it on the transputer unchanged.
PACT Parallel C is definitely not occam!
> After all, the security of occam could be
>a point to sell?? The lack of pointers, the abbreviations, the retyping,
>the othogonality of functions and procedures, the aliasing checks,
>the indenting (yes), the protocol with its associated checks, the no-out-
>of-memory insurance
Yes, the security of occam is useful in some situations. But because
some of the security is provided by the rather Orwellian approach of
removing features, the language ends up less secure when people find
themselves forced to hack around the language barriers and revert to
assembly, explicit stacks, etc.
> and least but not last - IT IS MUCH EASIER THAN C.
>It is probably too easy for C programmers - who actually would like to
>have structured assembler!
I don't find Occam easier than C. I know C, I like C and I like
being able to write powerful and concise code (with all those bad
things like recursion, pointers, data structures, etc.). It may well
be that you find Occam easier, but please don't tell me that I should
as well.
As for assembler, I thought Occam was the assembly language of the
transputer? :-)
>0yvind Teig
>Autronica, Trondheim, Norway
--
PACT Rob Kurver
Foulkeslaan 87 rob@pact.nl
2625 RB Delft ph: +31 15 616864
The Netherlands fax: +31 15 610032
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads