Direct PC-offset in assembler

[phx]

What code would you expect to be generated, when writing

        section code,code
        lea     2(pc),a0
        rts

And what code would you expect when writing

        org     $0
        lea     2(pc),a0
        rts

?

Many assemblers (Devpac doesn't) would encode the offset of 2 directly into the instruction, making the LEA effectively load the address of RTS. Is this an often used feature?

I'm currently working on improving the absolute ORG-mode in vasm and the second example gives me headaches, because labels and numbers are both becoming absolute. (The advantage is that any arithmetic operation will be allowed with labels.)

[StingRay]

I would expect the code in both cases to be generated as lea *+2(pc),a0. I wouldn't ever use something like this though.

[ross]

hmm, I would consider 3 different cases, but I change the ORG to $100 otherwise there would be accidentally two assembly with same encoding for ORG $0

•         section code,code
          lea     2(pc),a0
          rts

  =

  dc.w $41fa,$0002
  
  

•         ORG $100
          lea     2(pc),a0
          rts

  =

  dc.w $41fa,$ff00

  
  (so actually pointing to absolute location $2)

•         section code,code
          lea     *+2(pc),a0
          rts

  and
  

          ORG $100
          lea     *+2(pc),a0
          rts

  =

  dc.w $41fa,$0000

  
  (so really pointing inside the instruction)

[sparhawk]

In case of

lea 2(pc),a0

I would expect that it references the address 2 from the current PC (giving an error when it is out of range).

I think that in a real example yould actually write somethinng like

MyLabel:
   some code here
lea MyLabel(pc),a0

I think it would be rather unlikely that many people would write the "lea 2(pc)" instruction to point to the next instruction. If one really wanted that, he could always put a label there as well for referencing it. Otherwise this would mean that you would have to calculate the number of bytes the instructions take from the current pc, in order to get the correct offset.

[a/b]

Make it configurable via flag?
Putting everything aside, I'd say the expected is to encode the offset into instruction. It does make sense to me, since you are not referencing a label/symbol so the additional -2 adjustment for the opcode shouldn't be carried out.
But if you make it relative to *, I don't think it's wrong either. Just like devpac, asm-one family interprets it that way as well, so that's what I'd expect as the outcome. But theoretically, I find it 'less accurate'.
In such cases I'd generally go with how it already works (asm-one), but it's an interesting question to me (I'm working on something related), and I'd make it configurable with the default set to devpac-compatible.

[phx]

Thanks for the input. My feeling is also that an expression without any label or external symbol in it should be encoded directly, without subtracting the PC.

But what about this?

VECTAB  equ     $1000

        org     $100
        lea     VECTAB(pc),a0

(I would also encode it directly, which may be irritating.)

[sparhawk]

Why should this be any different than lea 2(pc).

lea 2(pc),a0

VECTAB EQU 2
lea VECTAB(pc),a0

Would you expect this to behave differently?

IMO the difference is only wether its a lable, meaning I want to point to the specified address, vs. a constant meaning I want that value.

You should mention this in the doc, though.

[ross]

Originally Posted by phx

But what about this?

VECTAB  equ     $1000

        org     $100
        lea     VECTAB(pc),a0

(I would also encode it directly, which may be irritating.)

This is the reason cause I prefer an offset that point to the absolute location (and a PC relative addressing is small and fast).
When I specify the ORG directive I want a direct access to this memory location.
If I want anyway a related to PC ptr I can use *.
(or a label for every other cases)

For normal SECTION, directly encoding the value is acceptable.

EDIT: apart, this is hacky code in Amiga

[Galahad/FLT]

I personally wouldn't ever use that, i'd directly reference the RTS with a label, I wouldn't ever reference something so close with that code.

[a/b]

External symbol (xref), not a 'regular' EQU/SET/= symbol. And also I wasn't sufficiently specific when I said label/symbol earlier.
So if it's a label or xref, use pc-relative addressing, otherwise encode specified offset.

[hooverphonique]

Maybe a bit OT, but what does the asterisk mean? Don't think I've seen that addressing mode before.

[a/b]

* = current address

[hooverphonique]

Originally Posted by a/b

* = current address

As in 1 word after the address of the opcode (i.e. the same value as PC) ?

[ross]

Originally Posted by hooverphonique

As in 1 word after the address of the opcode (i.e. the same value as PC) ?

No, the address of the instruction (first word opcode).

i.e.

   lea *(pc),a0
   rts

=

dc.w $41fa,$fffe

[phx]

Ross and Sparhawk have a point, expecting to handle 1234(pc) and label(pc) equally. It would be much more logical and also much easier to implement (I spent the last two days on terrible hacks for supporting direct encoding when there is no label in the expression). Also Volker urges me to refrain from any special handling.

So the question is also: how many old source texts would it break if 1234(pc) would be seen as a reference to address 1234 in absolute ORG sections? Probably not so many, when I read the answers here...?

I guess something like "JMP (2,pc,d0)" can be sometimes seen in jump tables, although I agree that I would always use a label or the '*'-symbol myself.

[phx]

Originally Posted by ross

No, the address of the instruction (first word opcode).

True for most assemblers, I think. Although there was a stupid assembler called PhxAss, which based it on the word after the opcode.

[ross]

Originally Posted by phx

true for most assemblers, i think. Although there was a stupid assembler called phxass, which based it on the word after the opcode.

[sparhawk]

The problem with "lea 2(pc)" is that it kind of defeats the purpose of using an assembler in the first place, if somebody expectes a direct encoding.

So you have some code like this:

   lea <target without label>(pc),a0
   move.w ...
   jsr bla
   btst bla
   beq somewhere
   ...
<target without label> move.l #1,d0

Now I would have to manually calculate the value, so that I can put it in the instruction. And if I change the code, I would have to do it all over again. Is this a real world use case? I bet there are not many sources which would rely on such a behaviour, and if, then they would be VERY hard to change.

Maybe somebody has an example where this indeed would be usefull?

[ross]

Originally Posted by phx

So the question is also: how many old source texts would it break if 1234(pc) would be seen as a reference to address 1234 in absolute ORG sections? Probably not so many, when I read the answers here...?

I have never seen it..

I guess something like "JMP (2,pc,d0)" can be sometimes seen in jump tables, although I agree that I would always use a label or the '*'-symbol myself.

I've always used *. Or a label.
On 000 offset is so tiny that in any case even using an absolute location would be inconvenient.

Originally Posted by sparhawk

Maybe somebody has an example where this indeed would be usefull?

It doesn't occur to me for normal SECTIONs...

[Kalms]

I expect that blah in blah(pc) or (blah,pc) to be a reference to a symbol or an absolute address. I expect it to never be a literal displacement value. If it ever can be a displacement value (like it is in blah(an)) then there is room for misinterpretation. I want the assembler to point out potential mistakes to me.


Therefore, I expect the following results:

	section	code,code

	lea	label(pc),a0
label:	rts

... will point a0 to the rts.

	section	code,code

	lea	$1234(pc),a0
	rts

... wil generate an error, since $1234 is supposedly a reference to an absolute address, and the assembler will be unable to compute the corresponding displacement within a non-ORG section.

        ORG	$100

	lea	label(pc),a0
label:	rts

... will point a0 to the rts.

        ORG	$100

	lea	$1234(pc),a0
label:	rts

... will point a0 to the absolute address $1234. (... and if absolute address $1234 happened to be more than 32kB away from the current instruction, I would expect the assembler to give an error that the displacement cannot be encoded as a 16-bit offset.)


If I ever want to encode an displacement (like, "read from 128 bytes ahead") then I would use a *+number encoding, like this:

	section	code,code

	lea	*+128(pc),a0
label:	rts

... will point a0 128 bytes ahead of the current instruction.

	ORG	$100

	lea	*+128(pc),a0
label:	rts

... will point a0 128 bytes ahead of the current instruction.


I don't know how good this particular strategy is for other legacy sources.