30 Aug
2006
30 Aug
'06
10:35 a.m.
An obscure unibus & pdp-11 question:
Does "clr" always do a DATIP (i.e. read-modify-write) on all 11's?
It does on my 11/44. Something tells me I've seen threads (long ago) on
this and the perils of using clr as opposed to "mov #0," when talking to
hardware.
The rl01 bootstrap does it talking to rl11 registers, which tripped me
up for a bit.
-brad
30 Aug
30 Aug
12:35 p.m.
From: Brad Parker <brad at heeltoe.com>
Reply-To: "General Discussion: On-Topic and Off-Topic
Posts"<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: DATIP from clr always? (obscure unibus & pdp-11 question)
Date: Wed, 30 Aug 2006 13:35:57 -0400
An obscure unibus & pdp-11 question:
Does "clr" always do a DATIP (i.e. read-modify-write) on all 11's?
It does on my 11/44. Something tells me I've seen threads (long ago) on
this and the perils of using clr as opposed to "mov #0," when talking to
hardware.
The rl01 bootstrap does it talking to rl11 registers, which tripped me
up for a bit.
-brad
The only difference between CLR and MOV #0 that I think of immediately
is that CLR clears the Carry flag too, whereas MOV #0 does not affect the
Carry flag. That is needed to do multi-word ADD or SUB.
- Henk, PA8PDP.
_________________________________________________________________
Windows Live Messenger: deel je foto's en bestanden
http://imagine-msn.com/messenger/launch80/default.aspx?locale=nl-nl
3:09 p.m.
"Henk Gooijen" wrote:
The only difference between CLR and MOV #0 that I think of immediately
is that CLR clears the Carry flag too, whereas MOV #0 does not affect the
Carry flag.
That is functionally correct, but I don't believe the two are
implemented that same (in microcode or hardware) in terms of what they
do on the UNIBUS.
My question was more, "in the various pdp-11 implementations", does CLR
generate a read-modify-write (DATIP,DATO) on all the machines?
A read-modify-write cycle on the unibus is not the same a normal read or
write. I thought I could just ignore it but it turns out I can't (but
it's not hard to support).
-brad
2:55 p.m.
Brad Parker wrote:
An obscure unibus & pdp-11 question:
Does "clr" always do a DATIP (i.e. read-modify-write) on all 11's?
It does on my 11/44. Something tells me I've seen threads (long ago) on
this and the perils of using clr as opposed to "mov #0," when talking to
hardware.
The rl01 bootstrap does it talking to rl11 registers, which tripped me
up for a bit.
-brad
On all the discrete logic 11s and LSI11 the CLR instr does a
DATI(P)/DATO sequence. This was done so that only one decode flow was
necessary for the single operand instructions that modified the
destination (ie, CLR/COM/INC/DEC/NEG/ROR/ROL/ASR/ASL/SWAB/ADC/SBC/SXT).
TST is a specical case, read source but don't write. CLR is the only
instruction that technically does not need to read the source operand,
but they did the read anyway and just ignored the value.
According to the PDP-11 CPU handbooks, the J-11 based designs did the
extra optimization so a CLR does not do the read, only the write cycle
(see item #36 in later handbooks).
So if your hardware can't tolerate a read access to a register, then you
can do a MOV #0,ADR instead of CLR ADR (and make a note in your code why
so some poor soul 30 years from now understands why you are doing a
non-optimal MOV #0,xxx!)
Don
3:13 p.m.
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, then you
can do a MOV #0,ADR instead of CLR ADR (and make a note in your code why
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
5:03 p.m.
Brad Parker wrote:
Don North wrote:
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...
Don
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, then you
can do a MOV #0,ADR instead of CLR ADR (and make a note in your code why
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
5:23 p.m.
Don North wrote:
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...
actually that's *exactly* the sort of thing I was hoping someone would
say... (so thanks!) not a digression at all.
-brad
31 Aug
31 Aug
8:29 a.m.
At 2:55 PM -0700 8/30/06, Don North wrote:
Brad Parker wrote:
For those that don't have this handy and to fully document the
discussion, here is the text of item 36 from the 1983-84 Architecture
Handbook:
CLR and SXT do just a DATO sequence for the last bus cycle: 23/24, J-11.
CLR and SXT do DATIP-DATO sequence for the last bus cycle: all others.
John
An obscure unibus & pdp-11 question:
Does "clr" always do a DATIP (i.e. read-modify-write) on all 11's?
According to the PDP-11 CPU handbooks, the J-11 based designs did
the extra optimization so a CLR does not do the read, only the write
cycle (see item #36 in later handbooks).
6687
days inactive
6688
days old
7 comments
4 participants
participants (4)
-
ak6dn＠mindspring.com -
brad＠heeltoe.com -
dundas＠caltech.edu -
henk.gooijen＠hotmail.com