Saving to 32 bits of GPRs in signal context

[Gabriel Paubert]

On Wed, May 30, 2007 at 09:44:44PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2007-05-30 at 00:32 -0500, Kumar Gala wrote:
> > > I think actually it would be useful to have the saving/restoring of
> > > the high 32 bits controlled by a prctl, so that programs have to ask
> > > explicitly for the new behaviour (and programs that don't want to
> > use
> > > the high 32 bits don't incur the extra overhead).
> > 
> > I like this, it means we can error if HW doesn't support it and  
> > requires applications to do something specific to enable the feature.
> 
> Yeah well.... I liked the prctl at first.. but then, I though twice :-)

I agree, sooner or later, distribution might install two copies in two 
different places and the dynamic loader will select one depending 
availability of 64 bit registers. At this point virtually all applications 
will effectively use 64 bit registers even when compiled in pure 32 bit 
mode but the prctl will have to stay only for "hysterical raisins".

In 32 bit mode, 64 bit divides use a libcall for example. But the
libgcc routine can and should use the 64 bit instructions. There are
many other libcall cases that would benefit from a libgcc compiled
to use 64 bit instructions (64 bit int to floating point conversions and
back). This indirectly affects a lot of functions.

	Gabriel (starting to having nightmares about somebody inventing
	just another processor flavor, like a 64 bit BookE processor 
	with SPE and Altivec).