Re: Porting GCC to a register-less, stack-less architecture

[Alexandre Courbot <Alexandre.Courbot@lifl.fr>]

> 	How are function calls handled?

Calls are performed by the Invok instruction, which takes the function
arguments as a parameter (might seems weird for an assembly language,
but it use less ressources than pushing, which is important for this
architecture). Arguments are taken back in the function body by
'.Arguments' declarations. For example, the following lines:

    .Arguments CardTB256 arg1
    .Arguments CardByte arg2 
    .Arguments CardByte arg3 

Would be the first lines of a function that takes 3 arguments.

There is also a return mechanism.

Others operations are quite classic. Arithmetic operations takes 3
arguments for example, which is just fine with GCC.

The architecture by itself might look a bit weird, but apart from the
fact it doesn't use a stack (which is only *absolutely* needed for
argument passing on others architectures anyway, right?) or hardware
registers, it's quite similar to others.

> 	Is all program storage statically declared?

You can declare new local variables with the .local statement. Note
however that my goal here isn't to have the libc working (no need for
mallocs and so on) but only to get GCC working ;) But if you asked
whether you allocate memory at the beginning of a block for example, the
answer is yes.

> 	Where are you planning on allocating compiler temporaries (e.g., if everything's a
> 	memory-memory operation, how do I compute
> 
> 		a = (b + c - d*a);
> 
> 	(You can't use 'a' as the target without great difficulty (you'll have to write an optimization pass....))
> 	Are you going to use static variables as temps?

I would use some local variables for this, as I can "dynamically"
allocate and de-allocate them.

> 	I'd think about defining a minimal set of "dummy" registers - just to keep the
> 	compiler happy with the SP and FP. And so that you have SOMEWHERE to allocate
> 	compiler temporaries.   (or you could just reserve a small number of memory locations,
> 	call them "registers" and let the compiler do the "register allocation" for those locations
> 	to treat them as temporaries.)  Assuming you have enough memory registers, you'll never
> 	spill until you get to a complex program - and maybe your users won't write complex code :-)

From what I understand, GCC use pseudo registers for temporaries, which
number isn't limited, right? So this is something I shouldn't have to
worry about, I guess. Unless I missed something. :)

> 	Then, assuming that I expect to never support function calls, I can map my "stack" onto a range of static
> 	variables when I emit the assembly language.  Anything that ends up "using" my pseudo registers in
> 	"funny ways" (like a _builtin_alloca_ would be defined with a DEFINE_INSN that prints an error message
> 	instead of emitting an instruction to the .s file...

Well, emulating a stack shouldn't be too hard on this arch anyway. But
if there is a way to do without (theorically it is possible, but I don't
know how much GCC likes such architectures) I'm taking it. :)

> 	Good strategy.  I'd pick a MD for a machine that you thoroughly understand, so you can see what it's
> 	doing and figure out if there's a correspondence to your architecture.  Off hand, I can't think of any
> 	machine that shares the characteristics of your architecture.

My knowledge is limited to the i386 architecture, which description is
quite complex (and which isn't as a "simple" architecture as I would
like). What I'm looking for is the most minimalist MD file you can set
up to get GCC to compile. Even if written for a different kind of
architecture, or a simple architecture I don't know yet, that's not a
problem - that would simply help me understanding GCC's mechanisms.

All in all, a .h and .md machine description files, the shortest
possible, which allows GCC to compile, would be paradise for me! :)

See you and thanks for the answer,
Alex.
-- 
http://www.gnurou.org