public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: Dave Brolley <brolley@redhat.com>
To: Ronald Hecht <ronald.hecht@uni-rostock.de>
Cc: cgen@sourceware.org
Subject: Re: Simulator and 24 Bit instructions
Date: Thu, 03 Aug 2006 20:07:00 -0000	[thread overview]
Message-ID: <44D25779.3080104@redhat.com> (raw)
In-Reply-To: <44CE298C.2040103@uni-rostock.de>

Ronald Hecht wrote:

> Attached you will find my current cpu-file.
>
> I'm having trouble to define the (add with carry)-instruction. If an 
> carry occurs, the accu becomes zero. Would you please have a look?

You likely are seeing some side effect of using the altered accu in the 
second part of the computation. You need to use a temporary, as you did 
for the ror insn. Something like:

(dni add "add"
     ()
     "add $uimm16"
     (+ OP_16 uimm16)
     (sequence ((WI tmp))
               (set tmp (addc accu (mem WI uimm16) cflag))
	       (set cflag (add-cflag accu (mem WI uimm16) cflag)))
               (set accu tmp))
     ()
)

>>
>> I'm having now problems with 24 Bit instructions in the simulator. I 
>> tracked down the issue to common/sim-trace.c. In 
>> sim_cgen_disassemble_insn() I found
>>
>>  if (insn_bit_length <= 32)
>>    base_length = insn_bit_length;
>>  else
>>    base_length = min (cd->base_insn_bitsize, insn_bit_length);
>>  switch (base_length)
>>    {
>>    case 0 : return; /* fake insn, typically "compile" (aka "invalid") */
>>    case 8 : insn_value = insn_buf.bytes[0]; break;
>>    case 16 : insn_value = T2H_2 (insn_buf.shorts[0]); break;
>>    case 32 : insn_value = T2H_4 (insn_buf.words[0]); break;
>>    default: abort ();
>>    }
>>
>> So 24 Bit instructions are a problem. I hacked
>>
>>    case 24 : insn_value = (T2H_4 (insn_buf.words[0]) / 256) & 
>> 0x00ffffff; break;
>>
>> and it works for me. But I think this might be a problem on big 
>> endian machines or is this hack ok?
>
>
As the one who added the test for (insn_bit_length <= 32) (many moons 
ago), I can say that your change does accomplish what was intended for 
your particular port. However, you are correct that there are endianness 
issues. Moreover, getting it right for the 24 bit case requires 
knowledge of how the insn fields are broken up. In your case, I suspect 
an 8 bit opcode and a 24 bit operand.

You need to write your own version of this function, 
<arch>_disassemble_insn and customize it to the needs of your target. 
Starting with sim_cgen_disassemble_insn should be fine. The function can 
go into sim/<arch>sim-if.c, and in sim_open (also in sim_if.c), you 
should change

  CPU_DISASSEMBLER (cpu) = sim_cgen_disassemble_insn;

to

  CPU_DISASSEMBLER (cpu) = <arch>_disassemble_insn;

I hope this helps,
Dave

      reply	other threads:[~2006-08-03 20:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-31  8:44 Ronald Hecht
2006-07-31 15:27 ` Frank Ch. Eigler
2006-07-31 16:00 ` Ronald Hecht
2006-08-03 20:07   ` Dave Brolley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44D25779.3080104@redhat.com \
    --to=brolley@redhat.com \
    --cc=cgen@sourceware.org \
    --cc=ronald.hecht@uni-rostock.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).