Re: delayed branches and zero overhead loops

[Joern Rennecke <joernr@arc.com>]

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.

> >It's the same situation with long immediates.  They are indicated by a
> >special value in any one of three operand fields.
> > 
> >
> Then this special value should be part of the fixed bits in the insn 
> description

But won't that require also fixed bits for the variant were there is a
register encoded in the register field?  With the general operations
form taking two operands that may or may not be a long immediate, encoding
each of the 61 core registers, long immediate and program counter read
encoded with constant bit patterns, that would explode the insn count by
a factor of 3969.

> >Speaking of which, is there a better way?  I've tried deleting individual
> >generated files or stamps, and some clean targets, but make always
> >floundered.
> > 
> >
> Usualy deleting the stamp-* files does the trick for me.

Which ones?