[LLVMdev] Backend for the ZPU - a stack based / zero operand CPU

[Øyvind Harboe]

> On Jun 19, 2008, at 2:30 PM, ?yvind Harboe wrote:
>> My llvm.org knowledge is ... shallow ... but I'm hoping that
>> someone would find the time & pity to answer my questions:
>>
>> Q: Is a stack based / zero operand CPU and llvm a good match? (GCC
>> wasn't)
>
> I'm not really sure, I'm not too familiar with these architectures.
> One advantage of llvm is that it is relatively easy to do custom code
> generation phases.  For example, you probably don't want to run the
> register allocator at all.

Not to run the register allocator would definitely be nice and probably
be a better match. It seems like you're implying that llvm uses trees.

The ZPU has two instructions that I'd also like to use. These instructions
can push a value from deeper down on the stack and also pop a value
from the stack and store them deeper down on the stack.

Calling convention was very tricky w/GCC since the ZPU only has
SP & PC. There are no registers to store the frame pointer, args
pointer in. Ditto for the return value, it must be stored on the stack.


>> Q: Can llvm help move global data into flash(i.e. determine that
>> global C
>> variables are in fact constants)?
>
> LLVM does aggressively mark globals as const when there are no stores
> to them.

The ZPU needs relaxation. Immediate values and
pc/sp relative references have variable lengths.

Does llvm support ìnstruction relaxation?

Can I use GAS or can/should I use llvm's assembler?

-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer