Re: literal pool support

[linas at linas dot org]

It's been rumoured that David Edelsohn said:
> 
> 	I am not suggesting creating a separate literal pool area, I am
> suggesting placing the literals in the data.  

Yes, I want to do this, I beleive I'll need to do this sooner/later to
get shared libs to work.  I've already got a patch to binutils that will 
disentangle the litpool support in the assembler to do this.  The trick 
is to do it without burning a yet another register, and I think I can 
recycle r12 for this.  But first, I have to go into gcc and houseclean 
out r12, which is strewn about like so many dirty dishes.

> GCC on AIX places literals
> directly in the TOC.  XLC creates a static pool and constants pool with
> addressibility to those pools provided through the TOC.

PowerPC also has 16-bit offsets, and can get away with 1 toc per subroutine 
in 99.99% of the cases. Ocassionaly someone generates a million-line-line 
subroutine with some whiz-bang tool, and finds they're SOL.  But the 390's
12-bit addressing requires multiple, sometimes dozens of pools per subroutine.

> that is how the i370 port works.  12-bits is not a lot of addressibility,
> but this is 12-bits per procedure, not per executable (like TOC and GOT).

I beleive many X11 programs would instantly overflow a 12-bit toc,
even if it were one per subroutine instead of one per executable.
Just take a look at the stuff in the motif includes in /usr/include/Xm.
But that's OK, I think I know how to manage multpile tocs/pools
per subroutine.  I think.  I'm still confused by the shared lib & pic issues,
so I'm not sure.  

--linas