| Hi all,
What I am trying to do is save CHAN OF SP, which was central to real Transputer system stuff.
Receiver:
CHAN OF SP grab : [32]BYTE buffer : INT16 len : SEQ grab ? len :: [buffer FROM 0 FOR (INT len)] -- STOP if len > 32 -- proceed with valid data in buffer
Sender: CHAN OF SP push : INT16 len16 : VAL []BYTE data IS "What are we doing here?" : SEQ len32 := INT16 (SIZE data) -- strictly less than 32 push ! len :: data
This is not at all similar to c ? a[i] :: a which I agree is incoherent and should be ruled out; but it does imply that len is input (and acted upon) before the input of the first few bytes of buffer. It is NOT equivalent to
grab ? len :: buffer
(read as a single input) despite what Conor says in his document, for three reasons: (a) that would provide no defense against len>32 and a buffer overflow, since len is unknown at the time of the single input; (b) the lack of knowledge of len would mean that if the input was the process that triggered a move in the "move"-type Transputer communication, it would not know how many bytes to move; (c) for the same reason, a link-type input would not know the correct place to stop.
CHAN OF SP simply does not work except as a two-step process. Any variant of occam needs to support CHAN OF SP or the equivalent, due to its extreme usefulness; I have even figured out how to do the equivalent in Go, and it was a very odd solution!
Larry Dickson
Hi all,
The occam 2 language allowed (for example) an input of the form c ? a[i] :: a.
This might leave the final value of the length variable, a[i] set to the length, or to a component of the array transferred, depending on i and/or the length of the array
transferred.
To avoid this, the assignments to the length and to the array were defined in occam
2.5/3 as being performed in parallel, preventing the example above, and making the
counted array input assignments consistent with parallel assignment (which, in
occam3, included array assignments).
There was never any intention to prevent variable length communications.
Best wishes
David
From: Larry Dickson <tjoccam@xxxxxxxxxxx>
Sent: 07 December 2018 01:53:33
To: David May
Cc: Occam Family; Brian Vinter
Subject: Re: Bad change in counted array protocol? Hello David and all,
I saw 19.4 and did not mention it because it led to the same conclusion as 19.2, and is subject to the same objections.
Disallowing a variable length to the buffer (based on len) conflicts with the rationale of the counted array protocol. Its purpose is to allow real time determination of the length of a data transmission. The length of the receiving buffer is the maximum allowed, but any size of transmission smaller than that can be allowed, which is very convenient for system-type IO and for IO of long data array sequences (like the output of a compression algorithm) that have a final member of unpredictable length.
The idea that the size of buffer has to be known ahead of time, which is what both 19.2 and 19.4 imply, requires a special transmission of len before the counted array. In other words, len must be transmitted twice. That seems to vitiate the whole point of a counted array protocol.
Larry
On Dec 6, 2018, at 3:55 PM, David May <david.may@xxxxxxxxxxxxx> wrote:
> Hi all,
>
> The rationale (19.2) is not correct.
>
> The issue is whether the assignment to len and the assignment to the buffer
> are performed sequentially - or not.
>
> This is set out in 19.4.
>
> David
>
>
>> On 6 Dec 2018, at 15:33, Larry Dickson <tjoccam@xxxxxxxxxxx> wrote:
>>
>> All,
>>
>> I took a look in detail at the definition of occam 2.5 in Conor O'Neill's document
>>
>> http://wotug.org/occam/documentation/oc21small.pdf
>>
>> and I found this:
>>
>> ======
>> 19 Counted array input . . . A counted array input of the form
>>
>> message ? len :: buffer
>>
>> is no longer permitted to refer to the len as part of the _expression_ buffer.
>> Note: This is a change from strict occam 2 behavior.
>>
>> 19.2 Rationale
>>
>> This makes it possible to treat the input at a single input . . .
>> ======
>>
>> He makes a concession to previous usage but makes it clear it is vacuous.
>>
>> This appears to make no sense. If len is an unknown-ahead-of-time value,
>> shorter than the target array, then it appears that (a) this opens the door
>> to buffer overflows, (b) in the "move" type of input, the inputting process
>> cannot know the size of the move, (c) in a link input, the link will not know
>> when the transmission is done and therefore will not know when to
>> reschedule the process.
>>
>> Did this change get adopted, i.e. put into occam-pi or any other
>> subsequent version of occam? It appears to destroy the entire purpose of
>> counted array protocol.
>>
>> Larry Dickson
>
|