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

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

On Wed, Nov 06, 2002 at 11:50:12PM +0000, cedric wrote:
[...]
> For me tjhe 256 entries tables is a database. It's still a lot. I know that a 
> good idea will be to preload into register each possible destination jump, 
> then look in the table for a constant and then do a conditionnal call to the 
> right destination. It can be quite quick and a good approach for the linking 
> process. 

In C, it's a `switch (opcode)' statement with 256 case labels but only
few different pathes. That is, a jump table will probably be fine.
I'll let the compiler choose the implementation, however ;)

> 	The problem is that will be an intruisive patch into gcc and ld...

It will be part of the F-CPU port of ld (it's done at link time),
and probably not more intrusive than the F-CPU port itself.

> > The allocation algorithm isn't complicated either (I outlined it in my
> > other mail).
> 
> Perhaps a little bit, but we know how to handle it correctly now. But you need 
> to see your function more like a graph than a tree, and you must for every 
> function that you don't know if they call somebody say that they call every 
> body !

It works vice versa: For every function that is *called* by unknown
functions (maybe because its address is passed as a pointer, or because
it is an entry point of a shared library), you'll have to provide a
wrapper that saves all registers that might be modified inside it, and
redirect the calls to the wrapper.

[...]
> > On the other hand, the `double jump' allows us to put multiple wrappers
> > around the same function without touching the function itself.
> 
> I was thinking that in the quick entry we didn't  save/restore register. So 
> that the wrapper can use the method they want for entering in this function 
> (with or without save, depending on the information they have).

The quick entry doesn't save/restore, that's right.

> > > With this you have both possibility. In fact you don't need to add a jump
> > > for entry point with your method too, because you can add the 2 entries
> > > points when you compile.
> 
> > The link time register reallocation relies on the fact that any number
> > of wrappers can be added to a function. That has to be done at link time
> > because the compiler doesn't know how many wrappers it has to provide.
> 
> We can have a default wrapper and many other that use the normal entry.

No - because they'll all have to use the same restore code if you jump
(or fall through) to the quick entry point without changing the return
address.

[...]
> > One might consider the `mask' approach as an alternative for the
> > program/library interface (after all, that looks like the weak point
> > of my approach). But there is a good argument against it: A reasonably
> > complex program will use *all* registers internally. That is, you always
> 
> Perhaps for a program, but not a librairie, and perhaps not between librairie 
> and certainly not every time.

A shared library (viewed from the outside) is just a collection of
`public' functions that always save the registers they use. If a
function uses only a subset, only that subset needs saving. But it's
quite likely that the subset used in the library will collide with the
one of the program, or with the ones of other shared libraries, so
unconditional save/restore seems to be the best guess.

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