Re: [f-cpu] New suggestion about call convention

[Michael Riepe <michael@stud.uni-hannover.de>]

On Wed, Nov 06, 2002 at 09:36:46PM +0100, Antoine wrote:
> 
> > > That means :
> > > - compiler capabilities
> > 
> > Can be added. Hey, it's Free Software, isn't it?
> 
> Of course. But I doubt adding something to gcc is very simple,
> especially if you want to do it cleanly so that the maintainers
> accept the patch. And in your case the patch might be quite 
> intrusive, because you are assigning new roles to both compiler
> and linker, and it's likely that gcc's current architecture
> isn't very adapted.

The changes to gcc are rather small. At a minimum, it should report
which registers a function uses, and where its code starts and ends
(the latter is already available, at least on Linux/ELF systems). An
explicit call tree would be nice, too. It's only a list of (caller;
callee) pairs that is easy to generate and process.

> > Note that GNU ld is not required on all operating systems;
> > gcc is usually capable to use the native linker (and assembler) of the
> > OS it runs on.
> 
> Yes. But whatever the linker, I don't think linkers are commonly
> assumed to mess with instruction codes & register allocation (even
> at function boundaries).

They perform relocations for memory addresses - why not for registers,
too? They also add code and data on their own when they build shared
libraries. There's absolutely nothing new, it's all been done before.

> So you may end up with custom versions of the gnu tools which will
> probably not be very compatible with the standard ones.

As long as the tools are free (in the GPL sense), where's the problem?

> Your proposal has another big problem : it ruins a part of the
> advantages of separate compilation. That is, if the linking part
> involves a costly optimization phase, rebuilding a whole project
> when changing just a source file will be much slower that it is today.

As I already pointed out, the register reallocation phase doesn't cost
much.

> > It shouldn't be more complex than the register allocation pass inside the
> > compiler. Just on a higher level - replace `instruction' with `function',
> > and you've got it.
> 
> Are you sure ? You are not dealing only with register numbers but also
> register quantities. It's one thing to allocate single registers, it's
> another to allocate variable-size register sets. Think about the 
> difference between a memory allocator that only allocates chunks of a
> fixed size, and another one that can allocate chunks of any size.

I guess `allocation' was the wrong term. The real allocation is still
done by the compiler, the linker only *re*locates them, as it does
with memory addresses.

> > Unused functions need no processing at all; in
> > fact, they may be removed during the process (another win).
> 
> You do not need all this analysis for such a win ;)

But you get it for free :)

> > Transposing a function
> > also requires linear time: each instruction is processed exactly once.
> 
> Well, either the object file carries information about the place of
> each register-bitfield needing to be transposed, or the linker does
> some on-the-fly disassembling (which makes it heavily architecture
> dependent, and is also not a very clean design imho). But I agree
> that on a pure operational point of view, this is ok. It's rather
> the optimization that bothers me.

Hmm... if the compiler would store register relocation entries in the
object file, processing could go even faster. But we don't really need
it. And yes, this *is* architecture dependent - it won't work on other
CPUs (memory relocation is CPU-dependent, too!), although it can probably
ported to another RISC CPU with a uniform register set and instruction
format.

> > The algorithm I have in
> > mind will simply process the call tree bottom-up (recursive functions will
> > be handled separately). 
> 
> What if recursion occurs at multiple stages and in non-trivial ways
> (between several functions and even several levels of the function
> "tree" - which is in fact a graph because of these recursions) ?

As I said, recursive functions will be handled separately (e.g. by always
saving all registers used internally). Note that this does not apply to
tail-recursive functions (which will be translated to ordinary loops by
the compiler).

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/