This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |