This is the mail archive of the gcc@gcc.gnu.org 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


Rask Ingemann Lambertsen <rask@sygehus.dk> writes:

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

For STACK_POINTER_REGNUM you just pick one of the general purpose
registers and don't use it for anything else.  You don't have to
define the push<mode> instructions, so you don't.  Instead you define
ACCUMULATE_OUTGOING_ARGS.  If you want some registers to be callee
saved, which you probably do, then you hand generate the prologue and
epilogue instructions; with the limited address space, you will
probably want to jump to a library routine to do it.

>   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
> Generation"):

Processors without jump to register indirect suck.  If instructions
and data are in the same address space, you can use self-modifying
code.  Making that both thread-safe and small is a pain, but you
probably don't have to worry about threads.

> 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
> target?

1024 instructions?  That is small.

Ian


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