Re: I need a GCC porting hint (or two) for an odd architecture...

[Nick Ing-Simmons <nik AT tiuk.ti dot com>]

Andrew Webber <andreww@videologic.com> writes:
>I might be off topic for this list for these questions...
>
>I have been playing around with porting gcc to an odd architecture.  The
>architecture is odd for a number of reasons, however, of most relevance
>to my questions are memory operations.
>
>In this architecture simple memory reads are actually made up of two
>machine instructions - one to issue the read address and one to pick up
>the read data.  

Cute.

>I have made a machine description that uses a define
>expand to split memory operations in the two parts but have come across
>a problem when optimization is turned on as the first of my two
>instructions gets optimized out (just before .c.flow is written out).  I
>could issue the two instructions as assembly together, however, I wanted
>to try going through RTL to see if I could use function units or
>whatever to reschedule these instructions to reduce stalling for memory
>reads.

When doing "odd architectures" it is best to lie to the compiler as little
as possible. So I suggest that the 1st insn should mention a "special" 
hard register (which represents the address or the read data) as an output, 
and the second mention it again as an input. 
That will build a dependancy between the two and you can add a "latency"
to the 1st insn so that second gets moved away from it.
It will get messy if this can be pipelined - i.e. several reads
in progress. It is easy enough to add more magic registers, but then GCC
will try and reorder the "collects" which may not match the pipelined arrival.

>
>In addition, my odd architecture consists of two groups of registers
>where for a memory write one group can be used for the write address and
>one for the write data - is there any pleasant way to communicate this
>to gcc (I currently use the inelegant solution of crippling the machine
>description to only allow write addresses from one group and write data
>from the other).

I am not sure I understand the restriction yet - but if two classes can be
swapped than you can give each class a name predicate etc. and have two 
alternatives:
       *class-1 = class2
or
       *class-2 = class1 

But GCC is not going to like it ;-) - REG_OK_FOR_BASE & co. get fixated
on the "one true base register" class.   

GCC is very bad at constraining registers where the choice of one hard 
register affects the validity of others. Many TI DSPs have similar restrictions
(e.g. which register is used as a "base" determines which registers are 
valid "index").  

I had (some) success by re-numbering registers in "pairs" (DI mode)
insisting that operands used the _same_ "pair" and then picking out High/low
as appropriate. I still tended to get a lot of register-register moves
that were not really necessary.  In your case I suecpect using 1/2 the 
possible registers like you do now is better than DI hackery.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.