Hello,

first of all, thanks for writing and maintaining this great program.
however, there seem to be some bugs related to assembling instructions with pc relative arguments.
pc indirect with displacement (programmers manual, 2.2.11) seems to be encoded wrong:

becomes 203a 6ead instead of 203a 7eaf ("The address of the operand is the sum of the address in the program counter (PC) and the sign-extended 16-bit displacement integer in the extension word")

also, the addressing mode pc indirect with index doesnt seem to be working at all, the instruction

which should become 203B B80F (programmers manual 2.2.12 / 2.1 / 4-118) gives an "displacement out of range" error.

Actually that is correct as the $7EAF is the absolute address of the target but is encoded relative to the current PC when the displacement is fetched, which is the word after the MOVE.l opcode.


Perhaps something is amis here... From Amiga assembly I seem to recall that


will calculate the displacement for you while


should accept the displacement value as is.

Anyone else?

Lee.

That was quiet a quick response

I see, so the value in front of the brackets is interpreted absolute. It's a little bit confusing, as displacement suggests something relative (what happens with negative values?).
I just tested gcc and amiga phxass, and they don't seem to distinguish between $x(pc) and ($x,pc). if $x is a value, they always interpret it as relative displacement, if it is a label, they interpret it as absolute and calculate the displacement.
however, the addressing mode "pc indirect with index" doesn't seem to be working at all, neither $x(pc,dn) nor ($x,pc,dn).
thanks for looking into it.

martin

EASy68K treats the numbers as absolute addresses and calculates the relative offset. This is consistent with the behavior of the Motorola, Teeside and Quelo assemblers.

_________________
Prof. Kelly