erf@blake.acs.washington.edu (John Firestone) (06/29/89)
I am designing a Q-bus controller and have come upon a PDP-11 architecture question which I hope someone can answer. If a MOVB instruction writes the low byte of a word-oriented device register, what does the high byte get set to? Thanks in advance for your help. John Firestone glug@geops.geo.washington.edu Geophysics Program, AK-50 University of Washington (206) 543-0162 Seattle, WA 98195
coburn@clo.dec.com (John T. Coburn) (06/29/89)
In article <2592@blake.acs.washington.edu>, erf@blake.acs.washington.edu (John Firestone) writes... >I am designing a Q-bus controller and have come upon a PDP-11 >architecture question which I hope someone can answer. If >a MOVB instruction writes the low byte of a word-oriented device >register, what does the high byte get set to? > >Thanks in advance for your help. > The high byte would be unchanged if the device register allows byte access. Otherwise the result would be undefined. -- John Employed by, but not representing Digital Equipment Corp.
bcw@rti.UUCP (Bruce Wright) (06/30/89)
In article <377@mountn.dec.com>, coburn@clo.dec.com (John T. Coburn) writes: > In article <2592@blake.acs.washington.edu>, erf@blake.acs.washington.edu (John Firestone) writes... > >If a MOVB instruction writes the low byte of a word-oriented device > >register, what does the high byte get set to? > > The high byte would be unchanged if the device register allows byte access. > Otherwise the result would be undefined. I think officially this is true - but in practice, essentially all implementations of the PDP-11 architecture will sign extend the byte to either all 0's or all 1's depending on the setting of bit 7. Bruce C. WrighT
jeuck@unix.SRI.COM (Philip Jeuck) (06/30/89)
In article <3054@rti.UUCP> bcw@rti.UUCP (Bruce Wright) writes: >In article <377@mountn.dec.com>, coburn@clo.dec.com (John T. Coburn) writes: >> In article <2592@blake.acs.washington.edu>, erf@blake.acs.washington.edu (John Firestone) writes... >> >If a MOVB instruction writes the low byte of a word-oriented device >> >register, what does the high byte get set to? >> >> The high byte would be unchanged if the device register allows byte access. >> Otherwise the result would be undefined. > >I think officially this is true - but in practice, essentially all >implementations of the PDP-11 architecture will sign extend the byte to >either all 0's or all 1's depending on the setting of bit 7. > > Bruce C. WrighT From the PDP11 Processor Handbook (digital 1981 - I know it's a little old but so am I): "MOVB - same as MOV. The MOVB to a register (unique among byte instructions) extends the most significant bit of the low-order byte (sign extension) into the high byte of the selected register. Otherwise, MOVB operates on bytes exactly as MOV operates on words." From my experience, MOVB does not sign extend on memory or I/O addresses; it does when the destinantion is a register (as the quote states). Only some warped I/O implementations from nonDEC vendors would require special precautions. Phil Jeuck jeuck@unix.sri.com
bcw@rti.UUCP (Bruce Wright) (07/02/89)
In article <597@unix.SRI.COM>, jeuck@unix.SRI.COM (Philip Jeuck) writes: > From the PDP11 Processor Handbook (digital 1981 - I know it's a little > old but so am I): > > "MOVB - same as MOV. The MOVB to a register (unique among byte > instructions) extends the most significant bit of the low-order byte > (sign extension) into the high byte of the selected register. > Otherwise, MOVB operates on bytes exactly as MOV operates on words." > > From my experience, MOVB does not sign extend on memory or I/O > addresses; it does when the destinantion is a register (as the quote > states). Only some warped I/O implementations from nonDEC vendors > would require special precautions. Essentially all modern devices are byte addressable, so this problem rarely comes up any more (modern in this context is probably anything post-1980). Paraphrasing from the 1974 Peripherals Handbook, the blow-by-blow details are as follows: The UNIBUS transactions that move data from the master (normally the CPU) to the slave are called DATO (word mode) and DATOB (byte mode). The bus control line C1 is set to 1 to indicate a DATO/B transaction, and C0 is set to 0 for a word transaction or 1 for a byte transaction. The address of the word is placed into the address lines A<17:1> (A<21:1> in more modern implementations). If C<1:0> = 10 then A0 is ignored (word mode transaction). If C<1:0> = 11, then A0 is set to 0 to indicate low byte (in which case the data byte is placed in data bits D<7:0> and the contents of D<15:8> are UNDEFINED), or A0 is set to 1 to indicate high byte (in which case the data byte is placed in data bits D<15:8> and the contents of D<7:0> are UNDEFINED). When a device which does not recognize byte mode transactions sees the DATOB on the bus, it ignores the state of the C0 control line and therefore it incorrectly loads the UNDEFINED bits into the other byte of its register (usually bits D<15:8>). My previous rather brief posting was referring to the behavior of these bits (I suppose it wasn't clear exactly what bits and what circumstances the posting was referring to). It turns out that in all of the PDP-11 implementations of which I am aware, the UNDEFINED bits (bits D<15:8>) are in fact a sign extension of the low order bits (bits D<7:0>). The problem was not restricted to third party devices. I remember my first encounter with RSX-11M V1.0 (!) was trying to boot it on our old RK05 (admittedly a low serial number ... but a real DEC part) and finding it looping in the bootstrap because it was running into exactly this sort of problem ... sign extending something-or-other into one of the RK11 registers, I forget the details now (gimme a break, it's been 14 years give or take). I have also written my share of PDP-11 device drivers on various DEC operating systems and on standalone PDP-11's and have run into this sort of thing from time to time ... I think with some of the old comm gear like early DL11's or DQ11's. I have not attempted to make an exhaustive list of devices and rev levels which have the problem, it's easier (after running into this a couple of times) to just restrict myself to word mode accesses unless I'm sure that all versions of the device support byte mode, and avoid angry customers. If you are writing commercial software even today it's probably best to practice defensive programming and not rely on MOVB's to leave the high order byte untouched unless the specs for the device specifically allow for byte mode I/O. Even DEC will tell you this: From the VAX/VMS V5.0 Device Support Manual (a guide for writing a device driver for VAX/VMS), page 5-3, final paragraph, final sentence: "All driver instructions that affect UNIBUS or Q22 bus device registers must use word context (for example, BISW, MOVW, and ADDW3) unless the register is byte addressable." Bruce C. Wright