[LLVMdev] Fw: Writing a backend for the ZPU

Samuel Crow samuraileumas at yahoo.com
Thu Nov 18 17:24:00 PST 2010


Whoops!  Forgot to CC: the list!



----- Forwarded Message -----
> From:Samuel Crow <samuraileumas at yahoo.com>
> To:Øyvind Harboe <oyvind.harboe at zylin.com>
> Cc:
> Sent:Thursday, November 18, 2010 7:22:39 PM
> Subject:Re: [LLVMdev] Writing a backend for the ZPU
> 
> 
> Hello,

Some 

> thoughts/problems:

- In GCC I created 
> registers which were just stack 
> slots in the
stack frame. This 
> allowed the reload and register allocation 
> to
do it's thing. What 
> kind pre-stackifier register file do I define
for 
> the ZPU?

- 
> In GCC I wrote a piece of C that recursively 
> unrolled
intermediate 
> representation to machine code instructions.
So any 
> treedepth was 
> fine as long as it consisted of
operations that were supported 
> by 
> the instruction set. I'm can't
get a handle on how to translate this hack 
> 
> to llvm so far.


A typical ZPU machine code add might look 
> something 
> like this:

a = a + b + 
> 123;

=>


    loadsp 
> 16 # push value at 
> memory location sp+16 onto stack
    loadsp 24 # 
> another 
> value
    add
    im 123
    
> 
> add
    storesp 20 # store back to original location. Notice 
> 
> 16+4=20


LLVM represents the above as something 
> like:

(set a, 
> (add (add a,b), 123)

Actually it represents 
> the code like this:

%1=load i32 @a
%2=load i32 @b
%3=add i32 %1, 
> %2
%4=add i32 %3, 123
store i32 %4, i32 @a

I'm not sure if that 
> helps you much though.  The virtual registers are write once due to static 
> single assign (SSA) form so there are an unlimited supply of virtual registers 
> in the bitcode stages of development.  I think you'll need to use a custom 
> register allocator since a stack machine has no real registers other than the 
> stack pointer.  In an older version of LLVM there used to be a backend that 
> would generate .NET code.  That might be something to look at.

I'm 
> sorry I couldn't help more,

--Sam Crow


      




More information about the llvm-dev mailing list