17 Sep
2002
17 Sep
'02
8:02 p.m.
On Sep 16, 17:40, Derek Peschel wrote:
On Tue, Sep 17, 2002 at 12:24:02AM +0000, Pete
Turnbull wrote:
> Pat is using PC-relative addressing -- probably inadvertantly. The 67
in
> that opcode 012767 means mode 6, PC-relative, so
the address actually
used
Is that why the apostrophes show up after the data? I had noticed them
and I know what they mean (relocatable data) but I thought it might be
the lack of correct pseudo-ops. Now I see there are no apostrophes after
the declarations at the beginning of the file, only after the later
references.
I'm not sure I would have defined
"relocatable" that way. (Even though
the
program never sets . it isn't marked as
relocatable, and there aren't any
external modules that can be relocated.) But it's still a useful
definition
if it catches errors.
Well, addressing mode 6 and 7 aren't meant merely to generate relocatable
code -- given suitable information, any linker can relocate code. Mode 6
and Mode 7 generate position-independant code (PIC), code that can be moved
at any time without alteration. The PDP-11 was designed to make that easy.
On Sep 17, 4:26, Derek Peschel wrote:
Pete, I replied to your other post in this thread.
I'm just trying to
understand what "the right thing to do" is here.
Well, I'd say the "right thing to do" is to use absolute addressing modes.
What modes 6/7 do is generate references which are relative to the
instruction address. They're meant for things that will move if the code
is moved (eg the target of a JSR). However, the address of a device
register doesn't move, so although it's possible to refer to using modes
6/7, it breaks the position-independance of the code. If you move the
code, you need to recalculate the address offset.
Once assembled, the first part of Pat's code, despite using mode 6, is not
PIC:
4 177564 XSR=177564
5 177566 XBUF=177566
6
7 001000 012767 000110 177566' MOV #110,XBUF
8 001006 105767 177564' L1: TSTB XSR
9 001012 100375 BPL L1
10 001014 012767 000064 177566' MOV #64,XBUF
11 001022 105767 177564' L2: TSTB XSR
12 001026 100375 BPL L2
13 001030 012767 000130 177566' MOV #130,XBUF
The actual values in the finally-assembled code would be (if I've done my
arithmetic correctly):
7 001000 012767 000110 176552 MOV #110,XBUF
8 001006 105767 176550 L1: TSTB XSR
9 001012 100375 BPL L1
10 001014 012767 000064 176536 MOV #64,XBUF
11 001022 105767 176534 L2: TSTB XSR
12 001026 100375 BPL L2
13 001030 012767 000130 17652 2 MOV #130,XBUF
Note that the pointers to XSR and XBUF change according to their position
in the code, because they're PC-relative (even if my PC-relative arithmetic
is wrong, the differences are correct).
Now if he'd written it using absolute addresses:
7 001000 012737 000110 177566 MOV #110,@#XBUF
8 001006 105737 177564 L1: TSTB @#XSR
9 001012 100375 BPL L1
10 001014 012737 000064 177566 MOV #64,@#XBUF
11 001022 105737 177564 L2: TSTB @#XSR
12 001026 100335 BPL L2
13 001030 012737 000130 177566 MOV #130,@#XBUF
... they don't change. Moreover, since there are no JMPs or JSRs, only
(relative) BRanches, this is PIC.
Now if he wanted to write it using a subroutine, and he used the simple
method:
7 001000 012701 000110 MOV #'H', R1
8 001006 004537 JSR R5, @#PUT
9 001012 012701 000064 MOV #'4', R1
10 001014 004537 JSR R5, @#PUT
11 001022 012701 000130 MOV #'X', R1
12 001026 004537 JSR R5, @#PUT
:
:
35 001100 105767 177564 PUT: TSTB @#XSR
36 001104 100375 BPL PUT
37 001106 010137 177566 MOV R1, @#XBUF
38 001112 000205 RTS R5
That's hand-assembled, in a hurry, so don't rely on the opcodes being
correct! but the point is that the subroutine is referred to by its
absolute address, so the first part of the code can be moved but not the
subroutine (because its address is fixed). However, if it were written
using relative addressing, ie
8 001006 004567 JSR R5, PUT
:
35 001100 105767 177564 PUT: TSTB @#XSR
then the whole thing can be placed anywhere in memory without alteration
(so
long as the subroutine stays in the same position relative to the rest).
Of
course, the subroutine still uses absoute addresses for the registers.
Does that make it clear what the point of the two types of addressing is?
My example is a bit contrived; that's not really how I'd do it. Instead,
I'd write a subroutine that wrote out a whole string, the string being
stored immediately after the JSR, and returning to the word after the
string. But that's another story.
--
Pete Peter Turnbull
Network Manager
University of York
18 Sep
18 Sep
2:08 a.m.
Pete Turnbull wrote:
On Sep 17,
4:26, Derek Peschel wrote:
Pete, I replied to your other post in this thread. I'm just trying to
understand what "the right thing to do" is here.
Well, I'd say the
"right thing to do" is to use absolute addressing modes.
What modes 6/7 do is generate references which are relative to the
instruction address. They're meant for things that will move if the code
is moved (eg the target of a JSR). However, the address of a device
register doesn't move, so although it's possible to refer to using modes
6/7, it breaks the position-independance of the code. If you move the
code, you need to recalculate the address offset.
Once assembled, the first part of Pat's code, despite using mode 6, is not
PIC:
4 177564 XSR=177564
5 177566 XBUF=177566
6
7 001000 012767 000110 177566' MOV #110,XBUF
8 001006 105767 177564' L1: TSTB XSR
9 001012 100375 BPL L1
10 001014 012767 000064 177566' MOV #64,XBUF
11 001022 105767 177564' L2: TSTB XSR
12 001026 100375 BPL L2
13 001030 012767 000130 177566' MOV #130,XBUF
The actual values in the finally-assembled code would be (if I've done my
arithmetic correctly):
7 001000 012767 000110 176552 MOV #110,XBUF
8 001006 105767 176550 L1: TSTB XSR
9 001012 100375 BPL L1
10 001014 012767 000064 176536 MOV #64,XBUF
11 001022 105767 176534 L2: TSTB XSR
12 001026 100375 BPL L2
13 001030 012767 000130 17652 2 MOV #130,XBUF
Note that the pointers to XSR and XBUF change according to their position
in the code, because they're PC-relative (even if my PC-relative arithmetic
is wrong, the differences are correct).
Now if he'd written it using absolute addresses:
7 001000 012737 000110 177566 MOV #110,@#XBUF
8 001006 105737 177564 L1: TSTB @#XSR
9 001012 100375 BPL L1
10 001014 012737 000064 177566 MOV #64,@#XBUF
11 001022 105737 177564 L2: TSTB @#XSR
12 001026 100335 BPL L2
13 001030 012737 000130 177566 MOV #130,@#XBUF
... they don't change. Moreover, since there are no JMPs or JSRs, only
(relative) BRanches, this is PIC.
Now if he wanted to write it using a subroutine, and he used the simple
method:
7 001000 012701 000110 MOV #'H', R1
8 001006 004537 JSR R5, @#PUT
9 001012 012701 000064 MOV #'4', R1
10 001014 004537 JSR R5, @#PUT
11 001022 012701 000130 MOV #'X', R1
12 001026 004537 JSR R5, @#PUT
:
:
35 001100 105767 177564 PUT: TSTB @#XSR
36 001104 100375 BPL PUT
37 001106 010137 177566 MOV R1, @#XBUF
38 001112 000205 RTS R5
That's hand-assembled, in a hurry, so don't rely on the opcodes being
correct! but the point is that the subroutine is referred to by its
absolute address, so the first part of the code can be moved but not the
subroutine (because its address is fixed). However, if it were written
using relative addressing, ie
8 001006 004567 JSR R5, PUT
:
35 001100 105767 177564 PUT: TSTB @#XSR
then the whole thing can be placed anywhere in memory without alteration
(so
long as the subroutine stays in the same position relative to the rest).
Of
course, the subroutine still uses absoute addresses for the registers.
Does that make it clear what the point of the two types of addressing is?
My example is a bit contrived; that's not really how I'd do it. Instead,
I'd write a subroutine that wrote out a whole string, the string being
stored immediately after the JSR, and returning to the word after the
string. But that's another story.
--
Pete Peter Turnbull
Network Manager
University of York 
2:36 a.m.
On Wed, 18 Sep 2002, Pete Turnbull wrote:
My example is a bit contrived; that's not really
how I'd do it. Instead,
I'd write a subroutine that wrote out a whole string, the string being
stored immediately after the JSR, and returning to the word after the
string. But that's another story.
FYI, I was trying to use that as an example to try and learn MACRO-11 (fun
stuff, eh?). I've made myself a subroutine version of the code also, I'm
not yet trying for reusable or well-written code, just something I can
quickly enter into ODT and see if what I did worked.
-- Pat
12:16 p.m.
On Wed, Sep 18, 2002 at 08:05:27AM +0000, Pete Turnbull wrote:
Sorry, I meant "the right thing for MACRO to do". Jerome and you didn't
seem to like the output format as it currently stands. How would you
change it? Jerome apparently wants to add some kind of warning lines.
Would you distinguish between ordinary relocation and PIC?
I'm really asking what the situations are (what the loader is capable of,
how you would define "relocatable" on the -11, tec.) as well as what
algorithms make sense to you.
I've been playing with the -10 where there's only one word per instruction
(though the left and right halves have their own loader flags) and the
address column as well as the data column can have an apostrophe in the
listing. I doubt PIC is a big priority on the -10 because it has always had
base/limit registers and, later, paging.
I tried the real MACRO (under RSX-11M) and it adds an apostrophe to the
initial setting of . (which is what I'd expect, since . was never given
a numeric value, only incremented from its default) but still no apostrophes
after the addresses later in the listing.
-- Derek
On Sep 16, 17:40, Derek Peschel wrote:
> On Tue, Sep 17, 2002 at 12:24:02AM +0000, Pete Turnbull wrote:
I'm not
sure I would have defined "relocatable" that way. (Even though
the
program never sets . it isn't marked as
relocatable, and there aren't any
external modules that can be relocated.) But it's still a useful
definition
> if it catches errors. Pete, I
replied to your other post in this thread. I'm just trying to
understand what "the right thing to do" is here.
Well, I'd say the "right thing to do" is to use absolute addressing modes.
What modes 6/7 do is generate references which are relative to the 
19 Sep
19 Sep
5:02 a.m.
I'm not sure what LINK does, and what input it
needs. It's a long time
since I used MACRO-11, but I'd have expected it to generate the "correct"
values, for a start. What Pat's output showed was:
7 001000 012767 000110 177566' MOV #110,XBUF
What it shows is the address which is supposed to be referenced.
The flag lets you know that relocation will be applied at link
time.
If it were to use the offset information in the listing, one
would have to do the calculation to see where it was actually
addressing (unless the listing were to add that info, but then
it would be too busy a listing, and comments would fall off the
edge of the paper since there wouldn't be room).
Not to mention the fact that the offset to an absolute location
would be different if the code were linked at a different location.
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | email: gentry at zk3.dec.com (work) |
| Unix Support Engineering Group | mbg at world.std.com (home) |
| Hewlett Packard | (s/ at /@/) |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 (DEC '77-'98) | required." - mbg KB1FCA |
+--------------------------------+-------------------------------------+
8130
days inactive
8131
days old
4 comments
5 participants
participants (5)
-
dpeschel＠eskimo.com -
jhfinepw4z＠compsys.to -
mbg＠TheWorld.com -
pat＠purdueriots.com -
pete＠dunnington.u-net.com