bugGNU Development Chain for 68HC11/68HC12 - Bugs: bug #6130, HC12 simulator bug with 16-bits...


You are not allowed to post comments on this tracker with your current authentication level.

bug #6130: HC12 simulator bug with 16-bits offset indexed indirect

Submitted by:  Stephane Carrez <ciceron>
Submitted on:  Thu 23 Oct 2003 07:38:13 PM UTC  
Category:  gdb Severity:  3 - Normal
Item Group:  sw-bug Status:  Fixed
Privacy:  Public Assigned to:  Stephane Carrez <ciceron>
Open/Closed:  Closed

Fri 28 Jan 2005 09:40:31 PM UTC, comment #1:

Fixed in 2.92 pre-release.

Stephane Carrez <ciceron>
Project AdministratorIn charge of this item.
Thu 23 Oct 2003 07:38:13 PM UTC, original submission:

From marc.brundler@atosorigin.com:


It seems there is a bug in the implementation of the 16 bits offset
indexed-indirect operations, in the HC12 simulator.The problem occurs
only when the PC is used as the base index register in those
instructions. Basically the problem is caused by the fact that when the
simulated PC is used to acces the operand, it does not point to the next
instruction but in the middle of the current one, causing an access 2
bytes before the expected one.

The output of my compiler (as shown by objdump) is :

802e: ff 80 3a lds 803a <_Startup+0x11>
8031: 07 cd bsr 8000 <Init>
8033: 15 fb 00 01 jsr [1,PC]
Disassembly of section .startData:

00008037 <.startData>:
8037: 00 bgnd
8038: 80 6c suba #108
803a: 0b rti
803b: ff 00 01 lds 1 <PORT_DIRECTION-0x7ff>
0000806c <main>:
806c: c6 ff ldab #255
806e: 7b 08 00 stab 800 <PORT_DIRECTION>

When this is executed in the HC12 simulator, the jsr [1,PC] instruction
jumps to 0x0100 (it has fetched this address at 0x8036), instead of
jumping to 0x806C (which it should have fetched at 0x8038). In other
words, at the time the value of the PC is fetched by the simulator, it
is 0x8035 (in the middle of the jsr) instead of 0x8037 (the start of the
instruction following the jsr).

The problem is in m68hc11_sim.c function cpu_get_indexed_operand_addr.
The code before and after the correction is :

/* [n,r] 16-bits offset indexed indirect. */
else if ((code & 0x07) == 3)
if (restrict)
return 0;
reg = (code >> 3) & 0x03;
addr = cpu_get_reg (cpu, reg);
addr += cpu_fetch16 (cpu);
/* We ensure the PC points to the
next HC12 instruction, in case cpu_get_reg is
called to get the PC value
addr = cpu_fetch16 (cpu); // Do this BEFORE cpu_get_reg
addr += cpu_get_reg (cpu, reg);
addr = memory_read16 (cpu, addr);
cpu_add_cycles (cpu, 1);


This correction solves the particular case I just described.
But :

- does this correction have side effects / is it general enough ?
- it seems there is the same bug few lines after in the same function,
when handling constant offset and accumulator offset indexed modes.
(haven't completely checked this yet).
- In the Motorola's "CPU12 Reference Manual" in the "Move instructions"
chapter, there is a special case described for PC relative adressing
with move instructions, that make me think that far more modifications
will have to be made for things to work in that case (however the same
manual says that "PC-relative indexing is rarely, if ever, used with
move instructions.").

-- Marc Brundler

Stephane Carrez <ciceron>
Project AdministratorIn charge of this item.


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


CC list is empty


Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.




Follow 2 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-01-28 ciceron StatusNone => Fixed
    Open/ClosedOpen => Closed

Back to the top

Powered by Savane 3.4