Re: delayed branches and zero overhead loops

[Joern Rennecke <joernr at arc dot 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.