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.
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
