This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Question on PowerPC setjmp/longjmp ABI


On Sat, Feb 17, 2001 at 12:03:37PM -0800, Geoff Keating wrote:
> If the ABI is already different (eg. between regular and soft-float),
> changing it more is OK, so yes, it's fine to shrink the jmp_buf
> structure.
> 
> Altivec is a different problem, because Altivec doesn't introduce a
> new ABI---you can link non-altivec code with altivec code, and this
> should work just fine.  I think what we'll have to do is increase the
> size of __jmp_buf, and version everything connected to it.

Well, it 'extends' the ABI.. Have you had a chance to look at the Altivec 
Programmer's Interface Manual?

http://e-www.motorola.com/brdata/PDFDB/MICROPROCESSORS/32_BIT/POWERPC/ALTIVEC/ALTIVECPIM.pdf

Also, from what I can tell, the SVR4 ABI specifies the size of jmp_buf, 
but the user-visible size is different.. Is this intentional? (I ask 
because the Altivec PIM says the jmp_buf size grows to 448 bytes for the 
SVR4 and EABI).

The PIM also specifies things like 'vec_malloc' which returns a 16 byte 
aligned address, and how altivec registers get saved on the stack frame.
 
> There've been a number of suggestions of things like this, that
> involve tweaking the ABI.  I've been trying to keep a list so that if
> we decide to do a big bang we can do them all at once.  At present,
> the list includes:
> 
> * long double == 128 bits
> * return small structures in registers
> * add altivec support to setjmp/longjmp

I'm curious how returning structures in (altivec) registers would actually 
help any, since to use data in a vector register in the integer unit 
requires writing that data to memory..

Also, I'm curious why the floating point and integer load/stores in
__longjmp.S & setjmp.S are interleaved... Wouldn't be be better (from a
performance and readability standpoint) to write/load the registers
to/from the jmp_buf in sequential order, since the largest bottleneck here 
is memory/cache bandwidth, not instruction scheduling/execution?

> 
> I think we can do all these profitably using symbol versioning for 
> glibc, but they'll have significant impacts on other shared libraries, 
> some of whose authors won't want to deal with it and will just step 
> the version number. > > --

-- 
--------------------------------------------------------------------------
Troy Benjegerdes                'da hozer'                hozer@drgw.net   

Somone asked my why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shulz had the best answer:

"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's why
I draw cartoons. It's my life." -- Charles Shulz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]