On 2015-12-23 21:36, Will Senn wrote:
All,
I have finished an analysis of the PDP-11 bootstrap loader code that may
be of interest to folks working with SimH. As many of y'all know, I am
pursuing a deeper understanding of Unix V6, which is pretty intertwined
with PDP-11 architecture, and in this day of virtual machines, the SimH
simulator (I don't have a PDP-11 laying around). Recently, my pursuit
has gone down the road of assembly language and machine code. In getting
a grip on these, I did a line by line analysis of how the bootstrap
loader loads the absolute loader (which loads other absolute format
paper tapes). Given that the bootstrap loader is 14 words long, you
would think it would be really straightforward. Maybe I'm slow, but this
turned out to be much more intricate a program than I thought it would
be. It's self-modifying and the addressing modes of the PDP-11 are a bit
difficult to work with (that and octal addition is strange to me).
I will follow up on this entry with a more user friendly writeup that
explains how loading DEC-BASIC is accomplished using the bootstrap and
absolute loaders.
Here is the link, I appreciate any feedback be it comments, suggestions,
or criticisms:
http://decuser.blogspot.com/2015/12/analysis-of-pdp-11-bootloader-code.html
I definitely do not want to discourage work like yours, or disparage it.
It's nice that people care and are interested.
That said, there are lots of things to comment on. First of all, I
wouldn't say that this bootstrap is capable of booting a large number of
peripherial devices. It can only read in the ABSLDR from paper tape, on
the PC11 paper tape reader.
What the ABSLDR then can do, is pretty much anything, but that is a
different program, and not the one you are analyzing.
Third, your disassembly, and notation is a little funky, while not
totally incorrect.
I think it would make more sense for you to write it this way:
START: MOV CSR,R1
LOOP: MOV (PC)+,R2
PTR: .WORD 352
INC (R1)
WAIT: TSTB (R1)
BPL WAIT
MOVB 2(R1),37400(R2)
INC PTR
BR LOOP
CSR: .WORD 177550
As for your analysis:
Your explanation of branches seems somewhat over complicated. The
instruction is indeed in just 8 bits, while 8 bits are the offset.
However, there is no need to mess things up with one-complement, or
tricks like that. The offset is an 8-bit value. Sign extend to 16 bits.
Multiply by 2, and add to the updated PC. Simple as that.
(Note that I said "updated PC". The PC will contain the address of the
instruction after the branch before you start doing the calculation for
the branch destination.)
In fact, no calculations are ever done in ones complement on the PDP-11.
You also make things a bit too complicated. An instruction like
MOVB 2(R1),37400(R2)
is encoded as (as you correctly said)
116162
2
37400
However, at execution, you should think of this as:
CPU fetches instruction - 116162
CPU increments PC
CPU starts evaluating first argument - 61 -> X(R1), meaning X needs to
be fetched from (PC).
CPU increments PC (because of addressing mode of argument 1)
CPU starts evaluating second argument - 62 -> X(R2), meaning X needs to
be fetched from (PC).
CPU increments PC (because of addressing mode of argument 2)
Don't start fooling around thinking (PC+2) and (PC+4). That will sooner
or later mess you up. It's always (PC), but PC gets incremented several
times.
Öater you also have:
"lines 8-10: store the read byte into the memory location referenced by
037400 + the new displacement, 000076
lines 11-12: increment the displacement to 000078, etc."
...it actually increments the displacement to 000077. It's only
incremented by one. Besides 8 don't even exist in octal. Had it
incremented by 2, it would have become 000100. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
