🚀 go-pugleaf

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