* Versioning longjmp etc.
@ 2003-10-17 20:47 Steve Munroe
2003-10-17 20:56 ` Ulrich Drepper
0 siblings, 1 reply; 6+ messages in thread
From: Steve Munroe @ 2003-10-17 20:47 UTC (permalink / raw)
To: libc-hacker; +Cc: sjmunroe
We are looking at integrating Vector Extensions (AKA Altivec or VMX) into
glibc for PPC32/PPC64. This will change the size of __jmp_buf and
sigcontext/ucontext and requires versioning of the corresponding functions
(setjmp/longjmp etc).
I assume this includes the complete function stack, for example
[siglongjmp | longjmp] -> [__libc_siglongjmp | __libc_longjmp] ->
__longjmp.
But looking at linuxthreads/ptlongjmp.c and nptl/pt-longjmp.c I don't
understand why we need the siglongjmp()/longjmp() stubs. They add
path-length without adding any function (at least in the current
implementation).
So could these stubs be eliminated and replaced with aliases? If they are
required where should I move ptlongjmp.c to (sysdeps/pthreads,
sysdeps/generic, ...) so I can override it for powerpc[32 | 64]? Or should
the siglongjmp()/longjmp() stubs be split out of ptlongjmp.c?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Versioning longjmp etc.
2003-10-17 20:47 Versioning longjmp etc Steve Munroe
@ 2003-10-17 20:56 ` Ulrich Drepper
0 siblings, 0 replies; 6+ messages in thread
From: Ulrich Drepper @ 2003-10-17 20:56 UTC (permalink / raw)
To: Steve Munroe; +Cc: libc-hacker, sjmunroe
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steve Munroe wrote:
> We are looking at integrating Vector Extensions (AKA Altivec or VMX) into
> glibc for PPC32/PPC64.
Why should this be necessary? It makes almost no sense at all to
include the content of these registers in the state. setjmp/longjmp are
probably never used in the middle of computations in which vector
registers are used. And if they are, this can be documented as the
users problem. Saving and restoring makes setjmp/longjmp much more
expensive and for absolutely no gain.
- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/kFdY2ijCOnn/RHQRAvV1AKCG60+FQvvHO8T+jlwlp/yQW9dCzQCeJgl+
b4S4ltS4kRTD203GeFs/Fc4=
=Zk67
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Versioning longjmp etc.
@ 2003-10-24 22:57 Steve Munroe
0 siblings, 0 replies; 6+ messages in thread
From: Steve Munroe @ 2003-10-24 22:57 UTC (permalink / raw)
To: Ulrich Drepper, libc-hacker; +Cc: Alan Modra, David Edelsohn
Need start over on this ...
Ulrich Drepper writes:
> Steve Munroe wrote:
> > We are looking at integrating Vector Extensions (AKA Altivec or VMX)
into
> > glibc for PPC32/PPC64.
>
> Why should this be necessary? It makes almost no sense at all to
> include the content of these registers in the state. ...
Because the ABI requires it.
<ftp://ftp.linuxppc64.org/pub/people/sjmunroe/PPC64-VMXabi.txt.gz>
VMX is treated like any other (GPRs, FPRs) register file. The ABI
specifies volatile and nonvolatile registers. Volatile registers are saved
by the caller (if it needs to preserve them) and nonvolatile registers are
"callee saved". With this definition setjmp/longjmp need to save and
restore the nonvolatile registers, including the nonvolatile vector
registers (v20-v31 and vrsave). VMX state is included only if indicated in
the AT_HWCAP. This will be handled similar the way AT_DCACHEBSIZE was
interrogated for powerpc memset.
> ... setjmp/longjmp are
> probably never used in the middle of computations in which vector
> registers are used.
That is difficult to enforce in the general case. As applications get
larger and more complex a single application may use a mixture of VMX and
non-VMX aware libraries. With call-backs the stack can easily include
non-VMX aware functions sandwiched between VMX aware layers. If this
middle(ware) layer gets control as the result of a signal and longjmp, the
VMX state must be restored before it returns to the initial VMX-aware
layer. Since the compiler (and code generated by it) was not VMX-aware, we
must depend on the runtime code (setjmp/longjmp).
Steven J. Munroe
Power Linux Toolchain Architect
IBM Corporation, Linux Technology Center
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Versioning longjmp etc.
@ 2003-10-17 22:27 Steve Munroe
0 siblings, 0 replies; 6+ messages in thread
From: Steve Munroe @ 2003-10-17 22:27 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: libc-hacker, sjmunroe
Ulrich Drepper writes:
> > How about get/set/make/swapcontext? The size of ucontext will change
as a
> > result of VMX state in sigcontext. This requires versioning.
>
> Hasn't it already changed? If not, yes, ppc sucks again and requires
> versioning.
Paul MacKerras submitted patches for PPC32 last month, PPC32 chips have
had VMX (AKA Altivec) for a while now. But the first PPC64 chips with VMX
have just started shipping (in the Apple G5) so this is a new issue for
PPC64. I've been waiting for the kernel headers (sigcontext) to settle.
BTW any man who thinks ppc sucks does not own a G5! ;)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Versioning longjmp etc.
2003-10-17 21:12 Steve Munroe
@ 2003-10-17 21:27 ` Ulrich Drepper
0 siblings, 0 replies; 6+ messages in thread
From: Ulrich Drepper @ 2003-10-17 21:27 UTC (permalink / raw)
To: Steve Munroe; +Cc: libc-hacker, sjmunroe
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steve Munroe wrote:
> I want to make VMX as usable as possible, without undefined behaviors or
> undocumented restrictions.
The compiler knows about setjmp/longjmp. It will store the register
content in memory around these calls.
> How about get/set/make/swapcontext? The size of ucontext will change as a
> result of VMX state in sigcontext. This requires versioning.
Hasn't it already changed? If not, yes, ppc sucks again and requires
versioning.
- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/kF6L2ijCOnn/RHQRAlHdAJ9A4RH/jAwsJhXqmE8bVm7D0ifjRQCgl/D1
Gzu0qB0CeOXCVzzmw4ejziA=
=qnEi
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Versioning longjmp etc.
@ 2003-10-17 21:12 Steve Munroe
2003-10-17 21:27 ` Ulrich Drepper
0 siblings, 1 reply; 6+ messages in thread
From: Steve Munroe @ 2003-10-17 21:12 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: libc-hacker, sjmunroe
Ulrich Drepper writes:
> Why should this be necessary? It makes almost no sense at all to
> include the content of these registers in the state. setjmp/longjmp are
> probably never used in the middle of computations in which vector
> registers are used.
For the future when gcc supports autovectorization.
I want to make VMX as usable as possible, without undefined behaviors or
undocumented restrictions.
How about get/set/make/swapcontext? The size of ucontext will change as a
result of VMX state in sigcontext. This requires versioning.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-10-24 22:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-17 20:47 Versioning longjmp etc Steve Munroe
2003-10-17 20:56 ` Ulrich Drepper
2003-10-17 21:12 Steve Munroe
2003-10-17 21:27 ` Ulrich Drepper
2003-10-17 22:27 Steve Munroe
2003-10-24 22:57 Steve Munroe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).