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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Øyvind Harboe
Hi all,

Zylin has implemented the world smallest 32 bit CPU with
a GCC backend. (I shall stand corrected if anyone claims
& proves otherwise :-)

Implementing a GCC backend for a zero operand/stack based
architecture proved pretty tricky, but I'm quite pleased with
the resulting code. I did make alterations to the architecture
to make it fit GCC without sacrificing CPU size.

I have been following llvm.org from a distance, since I finished
the GCC backend a couple of years back and there has not
really been a reason to build a new compiler for the ZPU.

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)

Q: Should I expect better code density / performance from llvm than GCC for
said architecture?

Q: Can llvm help move global data into flash(i.e. determine that global C
variables are in fact constants)?


The ZPU would probably be most effective in highly space constrained
applications(kBytes of code/data), such that it would fit entirely onto
an FPGA/CPLD. It has very high code density (~80% of ARM Thumb)

Overview of architecture(documentation is definitely the weak side of
the ZPU):

http://www.zylin.com/zpu_arch.html

The ZPU is now hosted at:

http://www.opencores.org/projects.cgi/web/zpu/overview

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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

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

Chris Lattner
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.


> Q: Should I expect better code density / performance from llvm than  
> GCC for
> said architecture?

Hard to say.  In general, LLVM has better high level optimizations  
than GCC, so if that is a factor, yes.

> 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.

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

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

Øyvind Harboe
In reply to this post by Ø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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

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

Owen Anderson-2
In reply to this post by Øyvind Harboe
You might try looking at the recent work on PIC16.  If you look  
through the list archives, one of  the developers wrote about his  
experiences using LLVM for such a constrained architecture.  To  
summarize: while LLVM didn't offhand support the oddities of his  
architecture, it was easier to modifying to work with them than other  
compilers he had worked with.

--Owen

On Jun 19, 2008, at 2:30 PM, Øyvind Harboe wrote:

> Hi all,
>
> Zylin has implemented the world smallest 32 bit CPU with
> a GCC backend. (I shall stand corrected if anyone claims
> & proves otherwise :-)
>
> Implementing a GCC backend for a zero operand/stack based
> architecture proved pretty tricky, but I'm quite pleased with
> the resulting code. I did make alterations to the architecture
> to make it fit GCC without sacrificing CPU size.
>
> I have been following llvm.org from a distance, since I finished
> the GCC backend a couple of years back and there has not
> really been a reason to build a new compiler for the ZPU.
>
> 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)
>
> Q: Should I expect better code density / performance from llvm than  
> GCC for
> said architecture?
>
> Q: Can llvm help move global data into flash(i.e. determine that  
> global C
> variables are in fact constants)?
>
>
> The ZPU would probably be most effective in highly space constrained
> applications(kBytes of code/data), such that it would fit entirely  
> onto
> an FPGA/CPLD. It has very high code density (~80% of ARM Thumb)
>
> Overview of architecture(documentation is definitely the weak side of
> the ZPU):
>
> http://www.zylin.com/zpu_arch.html
>
> The ZPU is now hosted at:
>
> http://www.opencores.org/projects.cgi/web/zpu/overview
>
> --
> Øyvind Harboe
> http://www.zylin.com/zy1000.html
> ARM7 ARM9 XScale Cortex
> JTAG debugger and flash programmer
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

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

Chris Lattner
In reply to this post by Øyvind Harboe
On Fri, 20 Jun 2008, [ISO-8859-1] Øyvind Harboe wrote:
> 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

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev