Re: 64-bit addresses and constant pools

[re not allowing pointers in the instruction stream]


In article <2054@osc.COM> jgk@osc.osc.COM (Joe Keane) writes:
>In article <162@gollum.twg.com> warner@twg.com (Warner Losh) writes:
>>I really don't see how this will solve your problems. You still need a
>>constant to offset into the constant pool. It would also make your compilers
>>much harder to produce since they would also have to manage a constant pool.


>I should say that when i wrote the original post i was thinking specifically
>about the ROMP architecture. ...


I wrote the original AIX ROMP C compiler. I did indeed use a constant pool.
Each routine had its own pool, and I collapsed multiple instances of the same
constant in the same pool, but if each of twelve routines refered to foo, even
in the same file, there were 12 pointers to foo. Since the ROMP and, I
expect, the America can handle 16-bit constants in the instructions, the
constant pool consisted mostly of addresses, a few floating point numbers
(floats where the low-order 16 bits are 0 are immediates), and a very rare
large integer. Handling the constant pool was trivial, and they were never
very large.


When we did shared libraries, the constant pool turned out to be an enormous
win because it put all absolute addresses in the non-shared data segment.
This let us map a library to different addresses in different programs without
any code fixups, since addresses in the code are all relative.


The astute reader may wonder what we did about the calling sequence since a
routine now has two addresses, the address of its code and the address of its
constant pool. My original thought was to do the same thing that TSS/360 did
to solve the same problem, which was to have two kinds of assembler external
pointer, a V-con which pointed to the code, and an R-con which pointed to the
static data, and have the linker resolve them. When we looked at the calling
sequence, this turned out to be a bad idea since it made function pointers 8
bytes rather than 4, and made the constant pool nearly twice as large.


What we did was to use the address of the constant pool as the address of the
routine (_foo) and always have the first word of the pool point to the code
(.foo). This made the calling sequence the same size as the other scheme, two
loads and a balr, and in the case where the routine was in the same source
file you could skip the second load and do a bali. I believe that they still
use the same scheme. Halfway through we changed the register we used for the
constant pointer in order to make the register save smaller, but other than
that it never caused any trouble.
--
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl

Return to the comp.compilers page.
Search the comp.compilers archives again.