Re: delayed branches and zero overhead loops

[Dave Brolley <brolley@redhat.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