Re: cross gcc port problem d,y ; 65 movhi/1

["Oleg I. Vdovikin" <vdovikin at jscc dot ru>]

Hello,

> This sounds just like our Motorola 68HC12 port.
    But this is not 68HC1x. ;-)) Index registers can't be used here as with
m68. Here is only 4 basic operation available for index registers: set the
index register to an immediate value, increment the index register with an
immediate value and moving it to and from the accumulator register.

> Third, make sure you have enough movXX alternatives.  The movXX insns are
> specal cases, in that unlike other insns, they can be generated in the
> reload pass.  You will probably need "rr" to/from "rN" alternatives, even
if
> these are inefficient.
    Yes, this alternatives presents.

    Today I've figure out the problem, but did not a solution for it. The
problems arises from the fact what this processor can't move the contents of
index register to the arbitrary memory locations, so when gcc wants to move
this register to the memory it needs secondary_reload, with accumulator as
the scratch register. So, I've defined SECONDARY_RELOAD_CLASS macro as
follows -

#define SECONDARY_RELOAD_CLASS(CLASS,MODE,X) \
    (class == BASE_REGS && GET_CODE(x) == MEM) ? BASE_REGS : NO_REGS;
    Also, I've defined reload_inX & reload_outX teplates in the md file.

    Unfortunatly when I'm trying to use gcc in this way I've got "Unable to
find a register to spill"...
    But when I've defined SECONDARY_RELOAD_CLASS as NO_REGS and add "m"
alternatives to the movqi templates, port will compile everything just fine,
but produces instructions which is not available on this processor. It's
possible to define sequence of instructions which will save accumulator
temporary, then performs move, and restores accumulator, but we've 2
disadvantages here - the first one is the unknown size of operand in the
accumulator (may be int, long, float) & the later is the emision of the
temporary saves/restores when the accumulator value does not realy matter.

    So the only problem now is the secondary reloads... :-((

>
> I'm not sure what to tell you here.  You can obviously work around this
> problem by saving and restoring rr within the instruction pattern.
    I've found the solution, which is pretty simple - just changing the

   (clobber (reg:QI 0))

to

   (clobber (match_scratch:QI 2 "=r"))

so the resulting insn for the

int compare(int a, int b)
{                        
    return a > b;        
}                        

    is 

(insn 10 27 11 (parallel[                            
            (set (cc0)                               
                (compare (reg:QI 0 rr)               
                    (mem:QI (plus:QI (reg:QI 3 r2)   
                            (const_int 4 [0x4])) 0)))
            (clobber (reg:QI 0 rr))                  
        ] ) 3 {cmpqi} (insn_list 3 (nil))            
    (nil))                                           
    
    It's funny, but gcc uses (clobber (reg:QI 0 rr)) as I've specified in the first pattern, which was rejected. ;-))

Thanks,
    Oleg.






------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com