Re: Support for 32-bit stack processors?

[Jim Wilson <wilson at specifixinc dot com>]

The Thodes wrote:
> I am wondering if GCC could be ported (as a cross-compiler, of course) to
> 0-operand, multiple-stack CPU's such as the Patriot Scientific IGNITE I/II.
> The requirements are:

This is very hard to say, as we have very little experience with stack 
machines, and you haven't provided any info about your target.  The x87 
FPU is really the only one that we have supported well, and that support 
works via the reg-stack pass.  This assumes you have enough registers to 
satisfy reload (at least 4), a way to exchange specific registers with 
the top of stack register, and maybe also other assumptions.  If your 
target is sufficiently similar to the x87 FP register stack, then an 
approach similar to reg-stack.c may also work for your target.

There was a picojava port for a while, but I think that one faked it by 
defining a virtual register file, and then using stack operations to 
operate on the virtual register file.  This same trick is also used by 
some target ports to 8-bit microprocessors that don't have enough 
registers for gcc to work.  You can pretend that there are registers in 
zero-page memory (or someplace else convenient), and then the patterns 
expand operation on these registers to multiple instruction sequences. 
This is not very efficient, but it will work.

> 1.)  Modify the register allocator to handle partially accessible stack
> caches and stacks kept partially in memory and partially in registers, as
> well as to avoid thrashing the stacks.

Sounds like trouble.

> 2.)  Modify reg-stack.c to handle the new architechure(s).

Should work if you have enough registers, and a way to access them.

> 3.)  Turn off "optimizations" such as CSE and some loop optimizations (such
> as hoisting loads and sinking stores out of loops) that would slow things
> down (due to excessive stack thrashing).

You can turn off entire optimization passes in the target 
OVERRIDE_OPTIONS macro, but it isn't clear if this will be a win, since 
completely disabling optimization passes may result in worse code than 
the stack thrashing you are worried about.

> 4.)  Fix the RTL generator to accommodate situations where operands are
> implied instead of being specified for  insns.

This should be handled in the target port.  I don't see why the RTL 
generator needs to know about this.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com