Re: wip-rtl status

[Andy Wingo]

Hi!

On Mon 04 Jun 2012 00:30, address@hidden (Ludovic Courtès) writes:

> Woow, this is dense.  ;-)

Yeah, sorry about that ;)  It has been difficult to get to a good
stopping point, and without that, I don't know how to organize my
thoughts :)

> Andy Wingo <address@hidden> skribis:
>
> Forget it if it’s too late, but would it make sense to first work on ELF
> as the container format and merge that in ‘master’, then merge wip-rtl
> on top?  It would be easier to digest.  ;-)

That's possible to do.  I don't think I would merge the bits that
statically allocate constants though, as it would entail changes to the
old VM, and it's probably not worth it.  So I would just throw our
existing bytecode into one section and link that to ELF, and use the new
loaders to load it.  Could be a good idea.


>> Instructions that take constants take them literally.  The various
>> emit-foo procedures will add the constant to a table if necessary, and
>> link-objects will serialize a constant table if necessary.  Not sure if
>> this is being too clever or not.
>
> I suppose the result is the same, whether the constant table is built at
> a level equivalent to GLIL or at some lower level.  So it may be more a
> question of which one is more easily or elegantly implemented?

Yeah, that's basically it.

>> Currently there are a couple of broken bits.  One is that we don't
>> currently write an init thunk, to fix up the car and cdr links in static
>> pairs, for example.
>
> Static pairs, as constant pairs stored on-disk?

Yes.  Consider a constant like '(1 . 2).  The car and the cdr are both
immediates, so you just allocate some space in the image for two words,
aligned on an 8-byte boundary, and you write the `object-address' of the
immediates directly in the words.

However something like '(1 . (2 . ())) has two pairs: the tail which has
two immediates, and the head that has an immediate in the car but a
pointer in the cdr.  In that case you need to patch up the cdr to point
to the tail, after you load the .go (or .so?) file.

The RTL text is position-independent, and the ELF linker tries to
separate read-only data from read/write data, so as to maximize sharing
among different processes.  But PIC data does mean that there will be
some relocations to initialize the internal pointers of static
constants.  That's what the init thunk does (or will do).

I could have emitted relocations into the ELF and had the loader handle
them, but this way we get to do our own kind of initialization, like
initializing immutable values as in string->symbol and string->number.

Andy
-- 
http://wingolog.org/