Motorola 68000程序计数器间接带索引（8位位移）寻址模式的正确汇编语法问询

Hey there! Let's untangle this confusion around the M68000's PC-indirect with 8-bit displacement + index register addressing mode—especially since you're dealing with disassembly and reassembly across VASM (mot syntax) and GNU as. Your initial breakdown of the 4EBB 0004 opcode as JSR (PC + 0x04 + d0) is spot-on for the raw machine code, but the syntax differences between assemblers come down to how they interpret your input, and what this addressing mode is actually designed for.

First: The Core of the Addressing Mode #

This mode calculates the effective address as:
EA = (PC) + (8-bit sign-extended displacement) + (Index Register)
The raw opcode stores that 8-bit displacement directly. Your original disassembly jsr ($04,pc,d0) is technically accurate for the byte pattern, but assemblers handle numeric values here differently depending on syntax and use case.

Case 1: Using Labels (The Intended Workflow) #

Both VASM and GNU as handle this mode flawlessly when you use a label instead of a hardcoded displacement. This is the standard way developers write code with this mode—you let the assembler calculate the correct relative displacement automatically, avoiding manual math errors.

VASM (mot Syntax) Example #

org $80
jsr (label,pc,d0)
nop
label:
nop

VASM computes the displacement between the PC (which points to the instruction after JSR, so $80 + 2 = $82) and the label ($86). The math works out to $86 - $82 = $04, which matches your original opcode 4EBB 0004. The listing confirms this:

00:00000080 4EBB0004  jsr (label,pc,d0)

GNU as (MIT Syntax) Example #

.org 0x80
jsr %pc@(label,%d0:w)
nop
label:
nop

GNU as does the same calculation, outputting the exact same 4EBB 0004 opcode. Using a label tells both assemblers you want the relative displacement to that target, not an absolute value.

Case 2: Using Hardcoded Displacements (The Confusing Part) #

When you use a raw numeric value instead of a label, the two assemblers interpret your input very differently:

VASM Behavior #

VASM treats numeric values here as absolute target addresses, not raw displacements. So when you write jsr ($04,pc,d0), it tries to calculate the displacement needed to reach $04 from the current PC. Since that's a huge negative offset, it either throws a "displacement out of range" error (if it can't fit) or encodes a truncated offset (like the 0x82 you saw, which is -0x7e when sign-extended).

GNU as Behavior #

GNU as (with its MIT-style %pc@(0x04,%d0:w) syntax) treats the numeric value as the raw 8-bit displacement, directly encoding 0x04 into the opcode. This matches your original disassembly, but when you run objdump on the result, it translates the displacement back into an absolute address relative to the PC—hence why it shows 0x6 (PC is $82, $82 + 0x04 = $86, so objdump displays the absolute target instead of the raw displacement).

Final Takeaways #

• For regular development: Stick to labels. Both assemblers handle this correctly, and it's the most maintainable approach (no manual displacement math required).
• For disassembly/reassembly:
  • If you're using VASM, adjust your disassembly output to use labels for unresolved addresses instead of hardcoded values. This avoids VASM interpreting them as absolute targets, which is exactly what you're planning to do—great call!
  • If you must use hardcoded displacements with VASM, you can force a literal value using the % operator, but this is rarely needed in practice.

内容的提问来源于stack exchange，提问作者msbit