This is the mail archive of the
cgen@sourceware.org
mailing list for the CGEN project.
Problem in decoding instructions in simulator
- From: "Shrirang Khishti" <shrirangk at KPITCummins dot com>
- To: <cgen at sources dot redhat dot com>
- Date: Fri, 21 Oct 2005 11:06:09 +0530
- Subject: Problem in decoding instructions in simulator
Hi all,
I am currently working on porting a simulator to a "16 bit LITTLE endian" architecture.
with instrctions having size 2 bytes as well as 4 bytes.
I am using cgen for it. I have done following things.
1. Added target specific cpu files to cgen source code
2. I am referring to m32r port and I have done corresponding similar changes to top-level
configure and also added some other files needed in sim/target folder.
3. I am building simulator using enable-cgen-maint option. And I have observed that
my target specific .c and .h files are generated in sim/target folder and also simulator
is getting built .
My main queries are
1. Though I have specified little endian in define-cpu construct in my target.cpu file
(define-cpu
(name target)
(comment "Target family")
(endian little)
(insn-chunk-bitsize 32)
(word-bitsize 16)
(parallel-insns 1)
)
I observed that in arch.h file which is generated from cgen it is defining following macro
#define TARGET_BIG_ENDIAN 1
Are there any other factors affecting this macro ?
2. My next query is regarding following dump code ..
400: e0 20 mov r0,#0x2
402: e6 f1 7b 00 mov r1,#0x7b
406: 00 01 add r0,r1
408: f0 10 mov r1,r0
40a: f0 20 mov r2,r0
40c: a8 20 mov r2,[r0]
40e: cb 00 ret
Although PC is at the location 0x400 instruction being decoded is from the location 0x402
What might be reason for this ?
This is dump of test object code for which I am debugging simulator with the help of native gdb.
Problem I am facing is that in targetbf_decode function pc is 400 which is correct but it is
showing base_insn (I think instruction opcode ) as F1 E6 ,which corresponds to opcode
from location 402. And after that it is incrementing cpu by
2 irrespective of instruction size, and decoding object file in BIG endian mode.
According to me this targetbf_decode is called from mloop.c file which is generated from
mloop.in file . I want to ask whether beacuse of this file , it is giving above behavior
or is there any other affecting factor ? Also is there any documentation about how to write
mloop.in file.
Thanks in advance
Regards,
Shrirang Khisti
KPIT Cummins Infosystems Ltd.