This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Backend for PicoBlaze

On Fri, Aug 25, 2006 at 06:06:47PM +0200, Armin Vogl wrote:
> Hello,
> I would like to ask if it would be possible to write a gcc backend for the
> Xilinx PicoBlaze soft processor.

   I'll make a few comments about it.

1. 8-bit wide registers (and ALU).

   GCC can generate disappointingly poor code for programs which deal with
data types larger than a register.

2. 16 general purpose registers.

   Normally, 16 registers would be considered enough, but when they are only
8 bits each, and the PicoBlaze is a load-store architechture, adding two
64-bit values would take all your registers, so if you want to support e.g.
64-bit C "long long int", it could become "interesting".

3. Register classes.

  It looks like you will only have NO_REGS and ALL_REGS, with GENERAL_REGS
being identical to ALL_REGS except for the condition code register. That's
the ideal situation for GCC.

4. Stack and argument passing.

   PicoBlaze has an internal call/return stack which can't be used for
passing arguments. How will the STACK_POINTER_REGNUM macro and the
"push<mode>" instruction pattern be specified?

5. Addressing modes.

  Very simple. An address is taken from a register or an immediate. As an
"interesting" feature, function address can only be immediate values. I.e.
jump tables and function pointers can't be used. Note that the GCC Internals
documentation, says (in the section "Standard Pattern Names For


	An instruction to jump to an address which is operand zero.  This
	pattern name is mandatory on all machines.

I don't see how it can be supported. But most programs don't need it.

6. Comparisons and condition codes.

  PicoBlaze only supports unsigned comparison. Extra instructions are needed
for signed comparison. Because of this, comparison instructions can't be
output until it is known how the comparison result is used. Delayed output
of the comparison is only a minor problem and some of GCC's existing targets
already do that.

> As I have never programmed anything like a compiler and am
> not familiar with gcc, I would like to ask how much time it would
> need to implement a backend. Is it realistic to do it myself or is
> there a place to request the addition of a backend.

I think it is realistic to get a PicoBlaze backend to the point where it
generates correct code in a month or two. Making it generate good code could
take several months. With "good code", I mean not significantly worse than
that generated by a human.

I suggest that before you do anything else, you figure out how to pass
arguments to functions and figure out an instruction sequence which performs
signed comparison.

The PicoBlaze has a program storage of at most 1024 instructions and a data
storage of 64 bytes. Is it really necessary and useful to port GCC to such a

Rask Ingemann Lambertsen

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]