Question about Coldfire JSR with PC indirect

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Question about Coldfire JSR with PC indirect

Jump to solution
1,318 Views
dan_filbey
Contributor II

I was analyzing the binary output of CodeWarrior v11 for an MCF5485 (Coldfire v4e) bareboard example project.

I found that this inline assembly routine:

asm __declspec(register_abi) void _startup(void)

{

   /* removed for brevity... */

   /* initialize any hardware specific issues */

   jsr __initialize_hardware

   /* etc... */

}

Resulted in the following machine code for the JSR  instruction:

4E BA 06 C2

Using the CFPRM (https://www.nxp.com/docs/en/reference-manual/CFPRM.pdf), the machine code maps to a JSR instruction with a source effective address of PC indirect with 16-bit displacement. PDF page 117 or printed page 4-41 of the CFPRM specifies the operation of JSR:

SP – 4 → SP; nextPC → (SP); Destination Address → PC

Section 2.2.8 of the CFPRM specifies how the PC indirect with 16-bit displacement addressing mode behaves: the operand pointer is calculated by PC (plus 2) plus the 16-bit displacement and the operand is the memory contents pointed to by this address.

Based on my understanding, using this addressing mode with JSR only makes sense if the operand in memory is the address of the subroutine. However, based on the contents of my output binary, this is not the case. Instead, the memory content at PC+offset is the machine code for the __initialize_hardware subroutine, and PC+offset is the address of the __initialize_hardware subroutine. Therefore, based on this interpretation, the behavior of the instruction would be erroroneous because the operand is not a valid address.

Now for my question(s): Does the PC indirect addressing mode behave differently for control flow instructions? Is the operand pointer used as the "Destination Address" of the jump instead of the operand itself? If so, where is this behavior specified? Because, this is the only way that the aforementioned instruction would produce the desired behavior.

1 Solution
1,221 Views
TomE
Specialist II

Actually the JSR handles the addressing mode the same way a MOVE does.

A MOVE to a register works out the effective address and then reads the data from that address into that register.

A JMP or JSR works out the effective address and then reads the data from that address into the instruction decoder. It loads an instruction the same way the MOVE loads data. As a useful side-effect it also loads that address into the program counter.

Does that make sense, or am I pushing the analogy too hard?

Tom

View solution in original post

3 Replies
1,221 Views
TomE
Specialist II

For Branches, the calculated "Effective Address" is the value loaded into the PC and not a pointer to memory to read to get that value.

The "JSR" page in the CFPRM specifies:

Source Effective Address field—Specifies the address of the next instruction, <ea>y; use the
control addressing modes in the following table:

That is similar to the "LEA" instruction, but different to the "MOVE" one, which is:

Destination Effective Address field—Specifies destination location, <ea>x

Tom

1,222 Views
TomE
Specialist II

Actually the JSR handles the addressing mode the same way a MOVE does.

A MOVE to a register works out the effective address and then reads the data from that address into that register.

A JMP or JSR works out the effective address and then reads the data from that address into the instruction decoder. It loads an instruction the same way the MOVE loads data. As a useful side-effect it also loads that address into the program counter.

Does that make sense, or am I pushing the analogy too hard?

Tom

1,221 Views
dan_filbey
Contributor II

Yes, your explanation makes sense. Thank you very much for the reply.

0 Kudos