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

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?

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.

Sounds like the Intel X87 floating point stack, which we support.

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

Does llvm support ├Čnstruction relaxation?

Yes, many targets (e.g. arm, mips, ppc) have branch offset restrictions.

LLVM doesn't provide an assembler, you should use GAS.

-Chris