This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Question on PowerPC setjmp/longjmp ABI
- To: Geoff Keating <geoffk at redhat dot com>
- Subject: Re: Question on PowerPC setjmp/longjmp ABI
- From: Troy Benjegerdes <hozer at drgw dot net>
- Date: Sat, 17 Feb 2001 15:50:04 -0600
- Cc: dmj+ at andrew dot cmu dot edu, libc-alpha at sourceware dot cygnus dot com
- References: <20010217133410.A3549@drow.them.org> <200102172003.MAA22373@geoffk.org>
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