Subject: Re: RX01

From: [email-masked] (Charles Lasner)
Date: 13 Dec 1993 00:13:12 GMT

In article <1993Nov28.223758.13904@crash>,
Jeff Makey <[email-masked]> wrote:
>In article <[email-masked]>, <[email-masked]> wrote:
>>The interrupt at the
>>end of the transfer of a sector between the RX01 interface and main memory
>>seems to be a really useless feature
>
>If you are writing to the disk, such an interrupt would tell you when
>the memory is available for some other use.  If you are in a hurry,
>this sure beats waiting until the real I/O is done.  If you are
>reading from the disk, it just tells you when your data is available.

Thank you for your comments on interrupts 101 :-).  However, the interrupt Doug
is complaining about comes about only at the synchronous point where the last
data word or byte is transferred.  It is caused by an instruction, not an
asynchronous operation that independently completed.  There is no overlapped
operation whatsoever as in normal interrupts.  For example, if you want to
read an RX01 sector, you first start a read operation of that sector into the
silo buffer.  For such an operation, an interrupt at the done point makes good
sense since you can go do something else until interrupted.  However, at the
point of the read-done interrupt, you now have to start a new operation called
empty-silo.  This is a protocol where the transfer flag will raise exactly
128 times to transfer a byte (or 64 times to transfer a word if a 12-bit
variant empty operation) at the somewhat annoying rate of several dozen
microseconds per data value, and the transfer flag does *not* cause an
interrupt!  This operation is essentially a foreground task enterred as either
the result after a read or inversely a silo-load preceding a write.  It takes
too long to be the chore of an interrupt handler, and makes no sense that way
if part of a write since it then precedes the interrupt.

When the last transfer is performed, the done flag also raises, thus the last
IOT to accomplish the last transfer no longer raises any additional transfer
flags (remember, they cause a skip only, not an interrupt!) but does cause
that done flag raise that will interrupt if so enabled.  The time between the
last XDR instruction and the done flag raise (meaning that SDN could now skip
and a done interrupt if enabled will occur) is just a handful of microseconds.
Thus, there is no point to that interrupt, since there's no processing to
overlap with.  Lazy software could use the done flag event to terminate the
data shoveling, but better software should count the data!

Note that non-interrupt boot, etc. code uses a so-called "figure-8" loop where
the transfer and done flag are both serviced as polled.  If transfer comes up
then transfer a word with XDR.  If done comes up then go on to some new
operation, etc.  This avoids the need to count, but it's still part of
"cross your fingers" boot coding, etc.

cj (Maybe I should teach Interrupts 102 :-)) l

---

From: [email-masked] (Charles Lasner)
Date: 13 Dec 1993 00:21:45 GMT

In article <[email-masked]>,
Greg Ewing <[email-masked]> wrote:
>In article <[email-masked]>, [email-masked] writes:
>|> The interrupt at the
>|> end of the transfer of a sector between the RX01 interface and main memory
>|> seems to be a really useless feature
>
>Not if you want to overlap processing with I/O. You start a
>transfer, then go away and do something else. The interrupt
>lets you know when the transfer is complete.

Wrong.  The interrupt occurs in less time than the overhead of handling
the interrupt takes to accomplish!  There is nothing to overlap with since
the done interrupt occurs a handful of microseconds after you finish the
last data transfer from the operation.  Remember, on the RX interface (and
even on the RX11) the data is transferred onesies, not DMA.  That happens
127 times, then on the 128th one you have been waiting for STR to skip on,
you do the last XDR and immediately there is a done interrupt that buys
you nothing but overhead.  IF DMA had been doing the transfer, then there is
something to overlap with, but you are an unwilling participant in each and
every data transfer!

cjl