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 authentification 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: gdbSeverity: 3 - Normal
Item Group: sw-bugStatus: Fixed
Privacy: PublicAssigned 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:

Hi,

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;
#ifdef ORIGINAL_CODE
addr = cpu_get_reg (cpu, reg);
addr += cpu_fetch16 (cpu);
#else
/* 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);
#endif
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 click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Fri 28 Jan 2005 09:40:31 PM UTCciceronStatusNone=>Fixed
  Open/ClosedOpen=>Closed

Back to the top


Powered by Savane 3.1-cleanup