NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/transput/1227

Text File | 1992-11-20 | 1.6 KB | 33 lines

Newsgroups: comp.sys.transputer
Path: sparky!uunet!inmos!titan.inmos.co.uk!news
From: [e-mail] (Conor O'Neill)
Subject: Re: Dynamic Memory Allocation (was Re: Why Occam3 probably won't be recursive)
Message-ID: <[e-mail]>
Keywords: Occam3 recursive, no
Sender: [e-mail]
Reply-To: [e-mail] (Conor O'Neill)
Organization: INMOS Limited, Bristol, UK.
References: <[e-mail]> <[e-mail]> <dbc.722086651@bill> <[e-mail]>
Date: Fri, 20 Nov 1992 14:01:41 GMT
Lines: 19

In article <[e-mail]> [e-mail] (Andy Newman) writes:
>    Yes we used CHAN OF ANY - it allowed our configuration langauage and
>communications system work! The two element vector holds the "to"
>channel and the "from" channel used to perform the RPC with the memory
>allocator process (this use exposed a limitation in the compiler, it
>assumed all channels in a vector were used in the same "direction")

This isn't a limitation of the _compiler_, it is a limitation of the
language: page 76 of the occam reference manual says that a channel
parameter may not be used for both input and output in a procedure.
This is so that an implementation can just remember that it's
either an `input channel array' or an `output channel array'
for usage checking, without having to keep a bit vector for each element.
It also means that arrays of unknown size are treated similarly.

---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: [e-mail]        US: [e-mail]
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".