Tunes LLL/i386

[Nathan Hawkins]

On Thu, 4 Apr 1996, Nathan Hawkins wrote:
> > [Relocation of Code words:
> > PIC can be done through relative and indirect addressing,
> > code relocation with complicated reloc descriptor,
> > or slow code recompilation is needed]
> Words can be made PIC within themselves. It's addressing other words, and 
> subsequently being linked to that is the problem. Now there are only 
> two solutions that I can see to that one:
> 
> 1. use absolute addressing, and never move anything.
> 2. use some kind of table of pointers. threading would have to be done 
> through the pointer table. GC could take advantage of this, however. :)
> 
> > > [Indirect addressing]
> >    The biggest problem about movable code is *return addresses*
> > (and more generally continuations, as a return address is just that).
> > If these are to be relocated, this means some costly behavior,
> > as we must be able to track down the beginning of any return code chunk.
> >    The first way to do it is to have some complicated call/receive
> > convention, so that return addresses always begin a code chunk,
> > or that some indirect or base+offset return address be used.

I've had a moment to look at the base+offset idea, and it looks like 
movable code /could/ be achieved this way. However, the expense might be 
a little high, for any processor. Some questions:

1. Would doing this provide a substantial gain for the GC, given that 
base pointers would always be used for calling words?
2. How frequently/likely are we going to need to be able to move objects?
3. Does the gain (hypothetical) aluded to in question #1 outweigh the 
performance loss of having a handful of extra instructions in each call?
4. Do the answers to question #2 & #3 make following up on this a low 
priority?

On the whole, you may be right, relocation may be considerably cheaper. 
But that has its own complications. Trouble is, I need to have some idea 
where to start.

*utsl*