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

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

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

Fixed in 2.92 pre-release.

Stephane Carrez <ciceron>
Group administrator
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>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

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.13-3230.
Corresponding source code