DATIP from clr always? (obscure unibus & pdp-11 question)
bqt at softjar.se
Thu Aug 31 01:53:41 CDT 2006
Don North <ak6dn at mindspring.com> skrev:
>Brad Parker wrote:
>> > Don North wrote:
>>> >> On all the discrete logic 11s and LSI11 the CLR instr does a
>> > ...
>> > thanks!
>>> >> So if your hardware can't tolerate a read access to a register,
>>> >> can do a MOV #0,ADR instead of CLR ADR (and make a note in your
>>> >> so some poor soul 30 years from now understands why you are doing a
>>> >> non-optimal MOV #0,xxx!)
>> > I fixed the hardware :-) I was just curious about which machines did
>> > what.
>> > The problem was that the two transactions are back to back and the bus
>> > master keeps overnership. I was waiting for BBSY to go away...
>> > -brad
>The 'original' use for DATIP-DATO (vs a sequence of DATI, DATO) was to
>let core memory know it did not have to do the read-restore cycle, since
>a DATO was coming right away to the exact same location and would
>overwrite with new data. The memory could then be a little bit faster.
>With MOS memory this is not necessary.
>Some later CPUs (11/74) iirc altered all the 'normal' memory accesses to
>be just DATI and DATO(B) cycles, and implemented the special sequence
>DATIP-DATOB for the ASRB instruction to act as the atomic memory
>interlock. But I digress...
I don't remember for sure here, but can't you have other times where
several transactions come back to back without the bus being released?
I really should look into the documentation, unfortunately it's not
where I am right now.
As for the 11/74, it didn't modify the interpretation of the Unibus
transactions, since the memory isn't on the Unibus. :)
The 11/7x memory bus do have a transaction that keeps the location
locked until a write have occurred however. Not used in the 11/70, but
the 11/74 uses that. (Obviously.) It's documented in the memory
subsystem manual for the 11/70. The only instruction using that bus
transaction is the ASRB howewer.
Not sure if the 11/84 might have redefined the Unibus somewhat. I
remember that there is some note about possible problems with some
Unibus devices in an 11/84, but I think it has to do with timing during
a bus reset.
Wish my memory was more accurate. :)
More information about the cctalk