Re: delayed branches and zero overhead loops

[Dave Brolley <brolley at redhat dot com>]

Joern Rennecke wrote:

> On Wed, Feb 14, 2007 at 12:08:21PM -0500, Dave Brolley wrote:
>  
>
> > Joern Rennecke wrote:
> >
> >    
> >
> > > I which that were the case.  Try to generate the decoder for the attached
> > > file; it warns about one alledged Decoder ambiguity for j_L_r_r 
> > > [$RC-noilink]
> > > versus j_L_r_r [$RC-ilink] .  The values for $RC-ilink and $RC-noilink are
> > > disjoint.  I've also tried to use a decode-split on this problem, but to
> > > no avail.
> > >
> > >      
> > The problem is that RC-ilink and RC-noilink are operands. They do not 
> > participate in insn decoding. If there are no other differences in the 
> > fixed fields of the insns (it's hard to tell because of the complexity 
> > of your pmacros),
> >    
>
> 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?

> 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

> If I want to know the expansion of a single macro, I find it more useful
> to use pmacro-expand interactively - the latency is also much lower than
> to rm -rf the entire build tree and then rebuilding.
>
> 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.

Dave