VLIW architectures

[Nick Ing-Simmons]

Dragos Badea <badrian@ss.pub.ro> writes:
>On Mon, 20 Mar 2000, Mike Stump wrote:
>
>> 
>> There is little to no support in gcc explicitly for VLIW.  In two
>> years time, there will be more.
>> 
>   
> Well, but do you have any suggestions for describing such an  
>architecture by present means? For instance, do you think I could make use
>of define_function_unit and insn attributes to get parallelism from the
>instruction scheduler ?

You can try. My experience with TI DSPs (TMS320C80 and TMS320C6XXX)
is that helps but you get stuck elsewhere. 
 
1. The register allocator gets in the way - it likes to keep a
   "variable" in one regsiter for all its life. On TI's DSPs
   at least registers and VLIW units are related so register allocation
   as GCC does it severly limits the legal functional units and hence
   parallelism.  GCC also lacks hooks to allocate regsiters based
   on functional unit in use so even if you force all registers into 
   short-lived pseudos (and GCC does not collapse them back again!)
   you find that final schedule fails to find as much parallelism 
   as pre-allocate schedule. 

2. Delay slot accounting is in terms of insn's - which on VLIW
   (and super-scalar come to that) is not the same as cycles.
   The same techniques that super-scalar processor use work,
   but with a deep pipe (8 delay cycles, up to 8 insn's/cycle)
   you are very unlikely to find 64 candidates for branch delay,
   and schedule in delay slots has more restrictions.
   
3. Other GCC/DSP issues are that GCC does not really have a clean
   way to force-fill delay slots for things like "load" instructions.
   TI's DSP don't stall in such cases, but just use the old value.
   So you end up with a custom output phase (like original MIPS port)
   which stuff in a lot of NOPs. This further invalidates the schedule
   to the function units...   

So if you are designing a VLIW machine for GCC try and make it as 
orthogonal as possible - allow any unit access to any register,
and build in hardware stalls when schedule fails.
Former costs Si area (=$) and later increases gate depth and so reduces 
MHz you can run so TI's DSPs don't do either - we use our own compiler
instead.
   
-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.