Hi! On Mon 04 Jun 2012 00:30, l...@gnu.org (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 <wi...@pobox.com> 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/
