public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: Ronald Hecht <ronald.hecht@uni-rostock.de>
To: Dave Brolley <brolley@redhat.com>
Cc: cgen@sourceware.org
Subject: Re: Simulator: base_insn and insn in decode.c
Date: Fri, 04 Aug 2006 08:51:00 -0000	[thread overview]
Message-ID: <44D30B5A.6070304@uni-rostock.de> (raw)
In-Reply-To: <44D270CF.30506@redhat.com>

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:

<snip>
 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;
</snip>

or

<snip>
 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;
</snip>

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

  parent reply	other threads:[~2006-08-04  8:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-31 11:58 Ronald Hecht
2006-08-03 21:55 ` Dave Brolley
2006-08-03 22:08   ` Dave Brolley
2006-08-07 14:39     ` Ronald Hecht
2006-08-07 14:53     ` Ronald Hecht
2006-08-14 21:19       ` Dave Brolley
2006-08-15  8:39         ` Ronald Hecht
2006-08-04  8:51   ` Ronald Hecht [this message]
2006-08-14 20:34     ` Dave Brolley

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=44D30B5A.6070304@uni-rostock.de \
    --to=ronald.hecht@uni-rostock.de \
    --cc=brolley@redhat.com \
    --cc=cgen@sourceware.org \
    /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).