[Simh] Writeup of PDP-11 bootstrap loader analysis

[Will Senn]

Johnny,

My comments are inline. I may not have understood everything you 
commented on, but I will :).

On 12/23/15 5:09 PM, Johnny Billquist wrote:
> I definitely do not want to discourage work like yours, or disparage 
> it. It's nice that people care and are interested.
>
Thanks, I invited criticism, not to worry. I wrote it because I wanted 
to understand it and unfortunately, no one else wrote anything I was 
able to easily comprehend (not that this was easy) in the hopes to help 
others. I'll improve it and appreciate your comments.

> 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.
I wrote that bit before I finished the draft. I have removed it and will 
edit a suitable substitute sentence later.
> Third, your disassembly, and notation is a little funky, while not 
> totally incorrect.
>
I'm sure. I am not an assembly language programmer and am learning as I go.

> 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
>
Sounds reasonable. I'll probably use it.
>
> 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.)
>
Ah, I mixed this up a bit. I will make edits that clarify along the 
lines you describe. What the analysis shows is how I, an inexperienced 
person, did the calculations. I will have to do some math practice, but 
I think I see how it works using the offset directly and will make edits.

> 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.

Hmm. Your explanation makes sense, I'll think about it and make some edits.

> Ö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
>
This was a typo. Thanks for catching it. I've edited it.