1

So I am working with coldfire (mcf5225x series) and I run into some issues with the jump encoding which in this case has the same binary representation as 68k.

asmtest.o:     file format elf32-m68k

Disassembly of section .text:

00000000 <_start>:
   0:   0682 0000 0040  addil #64,%d2
   6:   d481            addl %d1,%d2
   8:   4efa 0008       jmp %pc@(12 <exit>)
   c:   0682 ffff ffff  addil #-1,%d2

00000012 <exit>:
  12:   d081            addl %d1,%d0

As you can see the mode and register of the jmp instruction is 111010 which signifies a 16 bit word extension offset from the PC. The 16 bit extension is an 8hex offset from the current address 8hex. It should result in a 12 however, my math says I am getting a 10. What is the issue here, why does it seem like the wrong address to jump to is being generated? It is causing some issues in a processor model I am designing. Any help would be aprreciated!

PandaRaid
  • 618
  • 1
  • 9
  • 22
  • The offset is added to the PC value *after* the JMP instruction, so it looks correct to me. – Paul R Aug 16 '14 at 15:11
  • But it would be a 4 byte instruction... which means that it should be incremented by 4 and then added to offset which still gives the wrong value of 14 instead of 12. – PandaRaid Aug 16 '14 at 17:14
  • Oh yes, I see, that does look wrong then. – Paul R Aug 16 '14 at 17:27
  • 5
    [Just RTFM](http://www.freescale.com/files/dsp/doc/ref_manual/CFPRM.pdf), section 2.2.8 – Hans Passant Aug 16 '14 at 17:48
  • Cool, missed that statement. Still seems wierd that it is doing an increment of 2 rather than 4 but oh well. Thanks :) – PandaRaid Aug 16 '14 at 18:09
  • 2
    The really weird thing is that the code doesn't use BRA.b instead of JMP d16(PC) and also not SUBQ.l #1,d2 instead of ADDI.l #-1,d2. Optimizer turned off? – Durandal Aug 20 '14 at 18:19

0 Answers0