From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24901 invoked by alias); 4 Aug 2006 08:51:54 -0000 Received: (qmail 24892 invoked by uid 22791); 4 Aug 2006 08:51:53 -0000 X-Spam-Check-By: sourceware.org Received: from mailrelay1.uni-rostock.de (HELO antivirus.uni-rostock.de) (139.30.8.201) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 04 Aug 2006 08:51:51 +0000 Received: from antivirus.exch.rz.uni-rostock.de ([127.0.0.1]) by antivirus.uni-rostock.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 10:51:48 +0200 Received: from antivirus.uni-rostock.de (unverified) by antivirus.exch.rz.uni-rostock.de (Content Technologies SMTPRS 4.3.20) with ESMTP id for ; Fri, 4 Aug 2006 10:51:48 +0200 Received: from mail pickup service by antivirus.uni-rostock.de with Microsoft SMTPSVC; Fri, 4 Aug 2006 10:51:48 +0200 X-SCL: 5 71.46% Received: from mail.uni-rostock.de ([139.30.8.11]) by antivirus.uni-rostock.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 10:51:46 +0200 Received: from conversion-daemon.mail2.uni-rostock.de by mail2.uni-rostock.de (iPlanet Messaging Server 5.2 HotFix 2.09 (built Nov 18 2005)) id <0J3G00J01T9SMF@mail.uni-rostock.de> (original mail from ronald.hecht@uni-rostock.de) for cgen@sourceware.org; Fri, 04 Aug 2006 10:51:45 +0200 (MEST) Received: from [139.30.201.25] (pike.e-technik.uni-rostock.de [139.30.201.25]) by mail2.uni-rostock.de (iPlanet Messaging Server 5.2 HotFix 2.09 (built Nov 18 2005)) with ESMTPS id <0J3G00DM8TY9ZT@mail.uni-rostock.de>; Fri, 04 Aug 2006 10:51:45 +0200 (MEST) Date: Fri, 04 Aug 2006 08:51:00 -0000 From: Ronald Hecht Subject: Re: Simulator: base_insn and insn in decode.c In-reply-to: <44D270CF.30506@redhat.com> To: Dave Brolley Cc: cgen@sourceware.org Message-id: <44D30B5A.6070304@uni-rostock.de> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) References: <44CDF0AC.6070707@uni-rostock.de> <44D270CF.30506@redhat.com> 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/msg00021.txt.bz2 Dave Brolley wrote: > Ronald Hecht wrote: > >> Hello again, >> >> i found another problem in decode. c. As I have variable instruction >> size, decode.c does not handle base_insn and insn in the right way. >> The file looks like this: >> >> const IDESC * >> proc8bf_decode (SIM_CPU *current_cpu, IADDR pc, >> CGEN_INSN_INT base_insn, CGEN_INSN_INT entire_insn, >> ARGBUF *abuf) >> { >> /* Result of decoder. */ >> PROC8BF_INSN_TYPE itype; >> >> { >> CGEN_INSN_INT insn = base_insn; >> >> { >> unsigned int val = (((insn >> 0) & (63 << 0))); >> switch (val) >> { >> case 0 : >> if ((entire_insn & 0xff) == 0x0) >> { itype = PROC8BF_INSN_NOP; goto extract_sfmt_nop; } >> itype = PROC8BF_INSN_X_INVALID; goto extract_sfmt_empty; > > > The generated decoder expects base_insn to be the first base-insn-size > bits of the insn shifted as far right as possible. What you have > specified is correct and the (((insn >> 0) & (63 << 0))) test us > correct. It is looking at the low order 6 bits of the base_insn which > are the only significant ones (according to your cpu file. I completely agree with that. This actually works. > > The generated decoder expects entire_insn to the all of the insn bits, > also shifted as far right as possible. Yes, but im my case entire instruction starts at bit 23 with the instruction opcode. Bit 15 is the start of an 16 Bit operand. In the case of a 16 Bit instruction the opcode starts at bit 15 and then comes a 8 bit immediate. The decode functionality beneath decodes this correctly: extract_sfmt_lda: { const IDESC *idesc = &proc8bf_insn_data[itype]; CGEN_INSN_INT insn = entire_insn; #define FLD(f) abuf->fields.sfmt_lda.f UINT f_uimm16; f_uimm16 = EXTRACT_MSB0_UINT (insn, 24, 8, 16); /* Record the fields for the semantic handler. */ FLD (f_uimm16) = f_uimm16; or extract_sfmt_ldc: { const IDESC *idesc = &proc8bf_insn_data[itype]; CGEN_INSN_INT insn = entire_insn; #define FLD(f) abuf->fields.sfmt_ldc.f UINT f_uimm8; f_uimm8 = EXTRACT_MSB0_UINT (insn, 16, 8, 8); /* Record the fields for the semantic handler. */ FLD (f_uimm8) = f_uimm8; So this is correct, but the if clauses in the case statement should use the correct bits to double-check. As I mentioned, when I remove the if clauses, everything works fine. The simulator works as expected. > > The test around the goto is intended to make sure that the untested > base_insn bits are as expected. It needs to be there, otherwise, > invalid insns get recognized as valid ones. However, it would seem > that the test should be against base_insn and not against entire_insn. > I'll have a look at some other cgen simulators, including those which > use SID to make sure that this assertion holds water. It probably > hasn't come up until now, since most sims I have seen are able to pass > the same value for base_insn and entire_insn. > > Dave > I agreee. The test should be against base_insn. But then it still seems to be double-checking against the same, or not? By the way, I'm preparing a website holding the stuff about the processor and the tools port. It was pretty difficult to find some useful information about how to port the GNU tools starting from a very simple example. So I decided to put this information on this website. http://www-md.e-technik.uni-rostock.de/lehre/vlsi_i/proc8/ Ronald