Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
An underhanded programming problem.
30 views
Skip to first unread message
Mike B.
Jan 22, 2012, 5:14:57 AM1/22/12
to
Hi to all remaining transputer fans!
We start 2012 with a little programming problem. Below is a short
transputer assembler boot code sample. Who can say what’s wrong with
it?
Please take it with a pinch of salt – I will post the answer in a few
days.
-Mike
;
.t414
.pub _main
#define BOOT_CHAN_IN 1
#define BOOT_CHAN_OUT 2
#define BUFFER 3
_main
; make room for special workspace locations
ajw 5
; get input bootstrap channel address (held in register "C" on
entry).
diff
stl BOOT_CHAN_IN
stl BOOT_CHAN_IN ; save boot input link address
; compute corresponding output channel address.
ldc 4
bcnt ; Areg will be 8 for T2, 16 for T4/T8
ldl BOOT_CHAN_IN
xor
stl BOOT_CHAN_OUT ; compute boot output link address
; init high and low priority front of queue register
mint
sthf
mint
stlf
; init errorflag and haltonerrorflag
clrhalterr
testerr
repeat_loop
; read parameter
ldlp BUFFER
ldl BOOT_CHAN_IN
ldc 1
bcnt
in
; compute
ldl BUFFER
ldc 1
sum
stl BUFFER
; send result
ldlp BUFFER
ldl BOOT_CHAN_OUT
ldc 1
bcnt
in
j @repeat_loop
.end
; -=EOF=-
We start 2012 with a little programming problem. Below is a short
transputer assembler boot code sample. Who can say what’s wrong with
it?
Please take it with a pinch of salt – I will post the answer in a few
days.
-Mike
;
.t414
.pub _main
#define BOOT_CHAN_IN 1
#define BOOT_CHAN_OUT 2
#define BUFFER 3
_main
; make room for special workspace locations
ajw 5
; get input bootstrap channel address (held in register "C" on
entry).
diff
stl BOOT_CHAN_IN
stl BOOT_CHAN_IN ; save boot input link address
; compute corresponding output channel address.
ldc 4
bcnt ; Areg will be 8 for T2, 16 for T4/T8
ldl BOOT_CHAN_IN
xor
stl BOOT_CHAN_OUT ; compute boot output link address
; init high and low priority front of queue register
mint
sthf
mint
stlf
; init errorflag and haltonerrorflag
clrhalterr
testerr
repeat_loop
; read parameter
ldlp BUFFER
ldl BOOT_CHAN_IN
ldc 1
bcnt
in
; compute
ldl BUFFER
ldc 1
sum
stl BUFFER
; send result
ldlp BUFFER
ldl BOOT_CHAN_OUT
ldc 1
bcnt
in
j @repeat_loop
.end
; -=EOF=-
Mike B.
Jan 22, 2012, 6:41:32 AM1/22/12
to
Declaration of intention: The objective of the program should be that
I send 32bit values to a transputer on its boot link and get an
incremented value back on the same link. Overflows don’t care.
-Mike
I send 32bit values to a transputer on its boot link and get an
incremented value back on the same link. Overflows don’t care.
-Mike
Mike B.
Jan 24, 2012, 6:04:01 PM1/24/12
to
Let’s unravel the mystery!
The obvious bug is the IN instruction against the BOOT_CHAN_OUT. But
the unexpected effect is: There is NO PROBLEM at all – this program
works as intended!
Against a hard channel IN and OUT are interchangeable. So you can
compile this sample with IN/OUT, IN/IN, OUT/IN and OUT/OUT. All
combinations are well-functioning.
Why? The answer is simple: The hard channel itself determines the
direction. The IN or OUT instruction only contribute the pointer and
the length.
So you might ask: Why there are two instructions? They are required
for the internal channels. In that case the process which synchronizes
later determines the direction and dictates the length. The direction
and length of the first ready process is of no relevance.
This behavior also includes outword and outbyte.
repeat_loop
ldl BOOT_CHAN_IN
ldc 0
outword ; read parameter
ldl BOOT_CHAN_OUT
ldl 0
ldc 1
bsub ; compute
outword ; send result
j @repeat_loop
-Mike
The obvious bug is the IN instruction against the BOOT_CHAN_OUT. But
the unexpected effect is: There is NO PROBLEM at all – this program
works as intended!
Against a hard channel IN and OUT are interchangeable. So you can
compile this sample with IN/OUT, IN/IN, OUT/IN and OUT/OUT. All
combinations are well-functioning.
Why? The answer is simple: The hard channel itself determines the
direction. The IN or OUT instruction only contribute the pointer and
the length.
So you might ask: Why there are two instructions? They are required
for the internal channels. In that case the process which synchronizes
later determines the direction and dictates the length. The direction
and length of the first ready process is of no relevance.
This behavior also includes outword and outbyte.
repeat_loop
ldl BOOT_CHAN_IN
ldc 0
outword ; read parameter
ldl BOOT_CHAN_OUT
ldl 0
ldc 1
bsub ; compute
outword ; send result
j @repeat_loop
-Mike
Gavin Crate
Jan 27, 2012, 10:06:46 AM1/27/12
to
On Jan 24, 11:04 pm, "Mike B." <michael_brues...@yahoo.com> wrote:
> This behavior also includes outword and outbyte.
Hi Mike,
> This behavior also includes outword and outbyte.
Great investigation work!
I will update jserver to reflect your findings for ‘in’ and ‘out’
instructions.
Please can you clarify the behaviour of ‘outword’ and ‘outbyte’
instructions, based on you testing on the real transputer?
Since ‘outword’ instruction sends the data (i.e. 4 bytes) in AReg
using the channel in Breg, does that mean that if it actually does a
‘in’ instead (i.e. if external input address specified) does the data
(i.e. 4 bytes) end up in Areg, instead of Creg pointer location (which
happen for normal ‘in’ instruction).
The same question applies for the ‘outbyte’ case?
Regards
Gavin
Mike B.
Jan 27, 2012, 11:43:25 AM1/27/12
to
Hi Gavin!
> ‘outword’ instruction sends the data (i.e. 4 bytes) in AReg using the channel in Breg,
That is correct, but in fact the transputer saves the data word in
Areg at pw.temp and transfers this address (Wptr) to the link engine.
So the "received" word will end up in Wptr[0] and not in Areg. The
link engine can only access memory.
There is no practical usage to execute an outword against an in
channel. You saves one "ldc 4" for the costs of one memory reference.
Not a good deal!
The same behavior applies to outbyte. I don't know if the values of
the upper bytes of Wptr[0] are affected - but this counts for its
regular use also.
-Mike
> ‘outword’ instruction sends the data (i.e. 4 bytes) in AReg using the channel in Breg,
Areg at pw.temp and transfers this address (Wptr) to the link engine.
So the "received" word will end up in Wptr[0] and not in Areg. The
link engine can only access memory.
There is no practical usage to execute an outword against an in
channel. You saves one "ldc 4" for the costs of one memory reference.
Not a good deal!
The same behavior applies to outbyte. I don't know if the values of
the upper bytes of Wptr[0] are affected - but this counts for its
regular use also.
-Mike
Gavin Crate
Jan 30, 2012, 8:06:56 AM1/30/12
to
Hi Mike!
> So the "received" word will end up in Wptr[0] and not in Areg.
Now understood. I will update jserver to reflect your above findings
for ‘in’, ‘out’, ‘outword’ and ‘outbyte’ instructions.
Gavin
> So the "received" word will end up in Wptr[0] and not in Areg.
for ‘in’, ‘out’, ‘outword’ and ‘outbyte’ instructions.
Gavin
Gavin Crate
Feb 2, 2012, 4:16:04 AM2/2/12
to
Hi all,
For those who use my PC transputer emulator, there is a new updated
jserver 5.1e (beta) available on my website which adds the above
behaviour.
http://sites.google.com/site/transputeremulator/Home/beta-code
Regards
Gavin
For those who use my PC transputer emulator, there is a new updated
jserver 5.1e (beta) available on my website which adds the above
behaviour.
http://sites.google.com/site/transputeremulator/Home/beta-code
Regards
Gavin
0 new messages