From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12813 invoked by alias); 3 Aug 2006 20:07:35 -0000 Received: (qmail 12723 invoked by uid 22791); 3 Aug 2006 20:07:29 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Aug 2006 20:07:25 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k73K7OWZ010087; Thu, 3 Aug 2006 16:07:24 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k73K7MGU009396; Thu, 3 Aug 2006 16:07:23 -0400 Received: from [172.16.14.227] (IDENT:90DneFYSDnYkrH1w4PAIW2P/K9jN7kH9@topaz.toronto.redhat.com [172.16.14.227]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id k73K7MGi001257; Thu, 3 Aug 2006 16:07:22 -0400 Message-ID: <44D25779.3080104@redhat.com> Date: Thu, 03 Aug 2006 20:07:00 -0000 From: Dave Brolley User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) MIME-Version: 1.0 To: Ronald Hecht CC: cgen@sourceware.org Subject: Re: Simulator and 24 Bit instructions References: <44CDC354.9010502@uni-rostock.de> <44CE298C.2040103@uni-rostock.de> In-Reply-To: <44CE298C.2040103@uni-rostock.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2006-q3/txt/msg00018.txt.bz2 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, _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/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) = _disassemble_insn; I hope this helps, Dave