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

[Antoine <antoine@rezo.net>]

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

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

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


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.


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



> 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 ;)

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

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


> In addition to that, encapsulated code modules (e.g. object files) can
> be preprocessed to save compilation time.

You mean linking time.

> > For example, if you have three functions (A, B, C) that each
> > allocate 32 different registers. B calls C. A calls in turn :
> > C then B. So sometimes C is called from B which is called from
> > A, sometimes C is called directly from A. How do you think the
> > optimal solution will look like, and will that optimality be
> > satisfactory ?
> 
> In that case, you'll have to save registers at each call (assuming that
> you have no more than 32 registers available). Everything else requires
> a more detailed analysis of the code.

In fact my example was the same as yours, I was assuming 64 registers 
are available.



*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/