public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: Joern Rennecke <joernr@arc.com>
To: Dave Brolley <brolley@redhat.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>, cgen@sources.redhat.com
Subject: Re: delayed branches and zero overhead loops
Date: Mon, 19 Feb 2007 03:39:00 -0000	[thread overview]
Message-ID: <20070219033843.GA31910@elsdt-razorfish.arc.com> (raw)
In-Reply-To: <45D619DD.7010602@redhat.com>

On Fri, Feb 16, 2007 at 03:53:49PM -0500, Dave Brolley wrote:
> Joern Rennecke wrote:
> >On Wed, Feb 14, 2007 at 02:51:50PM -0500, Dave Brolley wrote:
> >  
> >>Joern Rennecke wrote:
> >>    
> >>>That is indeed the case.  The only format differences are in the
> >>>RC-ilink / RC-noilink operand and in the F0 / F1F operand.
> >>>
> >>>
> >>>      
> >>If so, then there must be more bits which are constant in each of the 
> >>two forms of the insn, otherwise, how does the hardware decode them?
> >>    
> >
> >ilink1 is core register 29, ilink2 is core register 30 .
> >Thus, you could describe the upper four bits of RC-ilink as 7,
> >but that would still not disambiguate it from RC-noilink for core registers
> >28 and 31.
> >  
> I would merge the two insns into one and handle the difference in the 
> semantic code by checking (index-of <operand>)

These insns have different syntax.
I.e. the RC-ilink variant has an optional operand which the RC-noilink version
hasn't.  AFAIK this can not be expressed in cgen with a single insn.

> >>>It's the same situation with long immediates.  They are indicated by a
> >>>special value in any one of three operand fields.
> >>>      
> This could be handled in the same way by checking the values of the 
> immediate operands.

You don't seem to quite understand the situation.  I have to check the
value of zero, one or two register fields in order to determine if the
long immediate field exists.

Therefore, I had to put part of the instruction fetch (the reading of the
long immediate) in the semantics of the instruction.

The knowledge about the instruction length is no longer in format field
of insn patterns in the .cpu file, but in mloop*.in .

With the length information already broken, I've also worked around the
decoder generator problem with generating negative shifts by pretending
that every instruction is 32 bit long; mloop*.in knowshaw to calculate that
actual lengths and how to fetch 16 and 32 bit opcodes, and represent them
as 32 bit opcodes.

  reply	other threads:[~2007-02-19  3:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-13 15:37 Joern Rennecke
2007-02-13 18:51 ` Frank Ch. Eigler
2007-02-13 21:00   ` Joern Rennecke
2007-02-13 21:12     ` Frank Ch. Eigler
2007-02-13 22:21       ` Joern Rennecke
2007-02-14 17:09         ` Dave Brolley
2007-02-14 18:30           ` Joern Rennecke
2007-02-14 19:52             ` Dave Brolley
2007-02-14 20:15               ` Joern Rennecke
2007-02-16 20:54                 ` Dave Brolley
2007-02-19  3:39                   ` Joern Rennecke [this message]
     [not found]                     ` <45D9C06A.4030903@redhat.com>
2007-02-19 15:56                       ` Joern Rennecke
2007-02-19 16:07                         ` Frank Ch. Eigler
2007-02-19 18:14                           ` Joern Rennecke
2007-02-19 18:19                             ` Dave Brolley
2007-02-22 15:50                               ` Joern Rennecke
2007-02-22 16:08                               ` insert evaluation for multi-ifields broken Joern Rennecke
2007-02-22 16:56                                 ` Dave Brolley
2007-02-22 18:14                                   ` Joern Rennecke
2007-02-23 17:45                                     ` Dave Brolley
2007-02-15 16:54               ` delayed branches and zero overhead loops Joern Rennecke
2007-02-14 18:58       ` decode-bitsize (Was: Re: delayed branches and zero overhead loops) Joern Rennecke
2007-02-13 19:25 ` delayed branches and zero overhead loops Doug Evans
2007-02-13 20:38   ` Joern Rennecke
2007-02-14 18:30     ` Doug Evans
2007-02-14 19:22       ` Joern Rennecke

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=20070219033843.GA31910@elsdt-razorfish.arc.com \
    --to=joernr@arc.com \
    --cc=brolley@redhat.com \
    --cc=cgen@sources.redhat.com \
    --cc=fche@redhat.com \
    /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).