lphillips@lpami.van-bc.UUCP (Larry Phillips) (03/30/88)
>I'm having a discussion with some co-workers about what an assembler should >do with an effective address of, for example, $20(PC). I think an assembler >should treat $20 as an offset, a co-worker thinks that an assembler should >treat $20 as an address. $20(pc) is defined by the blue Motorola book as a displacement added to the contents of the pc. From the Programmer's Ref manual, Fourth Edition, Page 20: This address mode requires one word of extension. The address of the operand is the sum of the address in the program counter and the sign-extended 16 bit displacement integer in the extension word. The value in the program counter is the address of the extension word. Sounds like an offest to me. That having been said, does it matter? In the example given, > tag equ $20 > move tag(pc),d0 tag is merely a value, without regard to type or purpose until it is used in an instruction. Used as it is, it becomes a displacement from the current pc of +$20, but it could have just as easily been used as part of an ASCII string to produce a space. Used as above, and considering it an address will produce exactly the same result as considering it a displacement. In both cases, the result will be the current pc contents added to $20. Sometimes you have to squint a little. -larry -- The transistor is a curiosity, and will never amount to much. -- Mr. Stringer, Basic Electronic Instructor, RCAF, 1962. +--------------------------------------------------------------------+ | // Larry Phillips UUCP: lphillips@lpami.van-bc.UUCP | | \X/ or: {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +--------------------------------------------------------------------+
lphillips@lpami.van-bc.UUCP (Larry Phillips) (03/30/88)
>I'm having a discussion with some co-workers about what an assembler should >do with an effective address of, for example, $20(PC). I think an assembler >should treat $20 as an offset, a co-worker thinks that an assembler should >treat $20 as an address. $20(pc) is defined by the blue Motorola book as a displacement added to the contents of the pc. From the Programmer's Ref manual, Fourth Edition, Page 20: This address mode requires one word of extension. The address of the operand is the sum of the address in the program counter and the sign-extended 16 bit displacement integer in the extension word. The value in the program counter is the address of the extension word. Sounds like an offest to me. That having been said, does it matter? In the example given, > tag equ $20 > move tag(pc),d0 tag is merely a value, without regard to type or purpose until it is used in an instruction. Used as it is, it becomes a displacement from the current pc of +$20, but it could have just as easily been used as part of an ASCII string to produce a space. Used as above, and considering it an address will produce exactly the same result as considering it a displacement. In both cases, the resulting effective address will be the current pc contents added to $20. Sometimes you have to squint a little. -larry -- The transistor is a curiosity, and will never amount to much. -- Mr. Stringer, Basic Electronic Instructor, RCAF, 1962. +--------------------------------------------------------------------+ | // Larry Phillips UUCP: lphillips@lpami.van-bc.UUCP | | \X/ or: {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +--------------------------------------------------------------------+
mph@rover.UUCP (Mark Huth) (04/09/88)
In article <1699@van-bc.UUCP. lphillips@lpami.van-bc.UUCP (Larry Phillips) writes:
.
. >I'm having a discussion with some co-workers about what an assembler should
. >do with an effective address of, for example, $20(PC). I think an assembler
. >should treat $20 as an offset, a co-worker thinks that an assembler should
. >treat $20 as an address.
.
.$20(pc) is defined by the blue Motorola book as a displacement added to the
.contents of the pc. From the Programmer's Ref manual, Fourth Edition, Page
.20:
.
. This address mode requires one word of extension. The address of the
. operand is the sum of the address in the program counter and the
. sign-extended 16 bit displacement integer in the extension word. The
. value in the program counter is the address of the extension word.
.
.Sounds like an offest to me.
.
. That having been said, does it matter? In the example given,
.
. > tag equ $20
. > move tag(pc),d0
.
.tag is merely a value, without regard to type or purpose until it is used
.in an instruction. Used as it is, it becomes a displacement from the current
.pc of +$20, but it could have just as easily been used as part of an ASCII
.string to produce a space. Used as above, and considering it an address
.will produce exactly the same result as considering it a displacement. In
.both cases, the result will be the current pc contents added to $20.
.
Well, actually, it does matter. If $20 is treated as an offset, then
the offset remains unchanged regardless of the assembler's program
counter at the time of assembly - that is, the assembler will generate
the same instruction and extension bit pattern for any location within
the program.
If, on the other hand, the $20 is treated as an address, then the
actual instrauction extension word generated wil vary with the
assembler's program counter. That is to say that the sequence
tag equ .
move tag(pc),d0
move tag(pc),d0
produces different extensions for each instance of the move
instruction. In fact, the latter case is the way most assemblers
treat pc-relative references. The Motorola reference cited above also
has a line that says "Assembler Syntax: LABEL(PC), where labels are
generally treated by the Motorola assembler as being of type address.
The value that goes in the extension word of the instruction is an
offset when the processor does its effective address generation at
execution time, but the assembler syntax will treat the label field of
the pc-relative reference as an address. This is as needed to
generate position independent code, the primary purpose of pc-relative
addressing.
Mark Huth