This is the mail archive of the
cgen@sourceware.org
mailing list for the CGEN project.
Re: delayed branches and zero overhead loops
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?