[LLVMdev] Creating an LLVM backend for a very small stack machine

[Wesley J. Landaker]

Hi folks,

I am interesting in creating an LLVM backend for a very small stack machine. 

Before I start in on the actual implementation, I'd like to make sure that 
I'm on the right track. Any comments, suggestions, warnings, tips, etc 
would be greatly appreciated.

Background
----------

There are a number of small as other embedded microprocessors that are often 
used in FPGAs such as Xilinx's Picoblaze, Lattice's Mico8, or Bernd 
Paysan's b16-small.

I am developping a very small stack machine primarily for use inside FPGAs 
and ASICs. This serves roughly the same niche as the above processors, 
however from my perpsective, my design has a number of advantages. For 
example, mine has a much smaller minimal configuration, has higher code 
density, is much more parameterizable, fully supports indirect branches, is 
FPGA-architecture independent, etc.

The main goal, however, is to not just have a shiny new architecture, but to 
have an entire optimized supporting toolchain. I am hoping to build on LLVM 
as infrastructure. I don't think I need to sell you all on the reasons why 
this would be handy.

I am already pretty "familiar" with LLVM, in that I have successfully made 
my own front-end DSL for another project by basically following the 
Kalidescope tutorial. I have a good grasp of the LLVM assembly language, 
and have a lot of notes (just a sanity-check paper excercize) about how I 
would lower just about every instruction into my architecture if I were 
doing it by hand. I've read through all the LLVM documentation available 
online, and (superficially) looked at a lot of the other backend targets. I 
have written custom assemblers and peephole optimizers outside of LLVM in 
the past. I am familiar academically with stack-machine specific "register 
allocation" optimizations. I'm basically ready to get started on an LLVM 
backend for my processor.

My main concerns are that in my searching online, I've gleaned a number of 
things that urge me to caution. I don't know how much of this is "true", 
but it's my impression after spending a lot of time googling:

  * A Picoblaze backend was apparently attempted both for LLVM and GCC, but 
apparently didn't go anywhere on either due to missing support for register 
indirect jumps, and possibly for other reasons. Of course my processor does 
support this, but ... 

  * There were a number of threads in various GCC lists and other places 
implying that, at least for GCC, targeting a stack machine would be very 
very difficult because of it's backend assumptions. Of course LLVM is not 
GCC, but TableGen seems register-biased ...

  * There seems to be a (to me) strange negative vibe whenever someone 
brings up targeting a compiler to a very small microprocessor, usually 
including an argument that it's not worth it. Of course, I'm the one doing 
the work, and I already have decided it's worth it ...

Anyway, hopefully that gives you an idea of where I'm coming from. Before I 
get too knee-deep into writing a backend, I have a few questions that I 
hope someone can help me with.

Questions
---------

  * Has anyone else out there targeted (or tried to target) a stack machine 
before? Was it successfull? What problems did you have? 

  * What parts of the LLVM backend code generator infrastructure would be 
usable for targeting a stack machine? e.g. Is it even possible to use 
TableGen to target a stack machine?

  * When/where/how do things like big integer (iXXXXX), phi nodes, llvm.* 
instrincs get lowered; e.g. does my target have to do that, or is it done 
generically?

Ultimtely, I'm wondering if targeting a stack machine with the current LLVM 
infrastructure is going to be somewhat straightforward even if it's not 
totally optimal (desirable), or if it's going to be so problematic that I'd 
be better off implementing an entire new code-generator myself 
(undesirable).

Any other comments or discussion is welcome.

All of my work (hardware design and all software) will be publicly and 
freely available.

-- 
Wesley J. Landaker <wjl at icecavern.net> <xmpp:wjl at icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090222/4db71cb1/attachment.sig>