Altivec and binary compatibility

Altivec and binary compatibility

[Adrian Cox]

Altivec raises an interesting question of binary compatibility, in the
area of C++ exceptions and \x03C setjmp/longjmp.

As the jmp_buf is a different size in Altivec and non-Altivec code, it
is not possible to jump or pass exceptions between the two. This is a
problem, because:
1) Now would not be a good time to change the size of a jmp_buf.
2) We do not need two incompatible 32-bit PowerPC ABIs under Linux.
2a) Most libraries installed by a distribution will be non-Altivec code,
to avoid having both G[123] and G4 binary variants of the distribution.

To add to the problem, throwing exceptions on an error is just what a
modern C++ library is supposed to do.  Throwing or catching an exception
in Altivec code will produce sequences that cannot execute on a G3
(which is precisely what got me considering this).

Does anybody have any bright ideas, beyond ensuring that everybody
restricts the use of Altivec compilation to routines which only call
safe functions? As long as Altivec code requires the vector keyword,
that's probably a reasonable assumption.

- Adrian Cox, AG Electronics

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Altivec and binary compatibility

[Giuliano Pochini]

> Altivec raises an interesting question of binary compatibility, in the
> area of C++ exceptions and \x03C setjmp/longjmp.
>
> As the jmp_buf is a different size in Altivec and non-Altivec code

Because with Altivec we need to save V registers, right ?  Well, I suppose
intel developers had the same problem with P-III "vector" unit. How did they
solve the problem ?

> it is not possible to jump or pass exceptions between the two.
> This is a problem, because:
> 1) Now would not be a good time to change the size of a jmp_buf.
> 2) We do not need two incompatible 32-bit PowerPC ABIs under Linux.
> 2a) Most libraries installed by a distribution will be non-Altivec code,
> to avoid having both G[123] and G4 binary variants of the distribution.

I agree.

> To add to the problem, throwing exceptions on an error is just what a
> modern C++ library is supposed to do.  Throwing or catching an exception
> in Altivec code will produce sequences that cannot execute on a G3

Why ?? (sorry for my ignorance...)

Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Altivec and binary compatibility

[Adrian Cox]

Giuliano Pochini wrote:
Giuliano Pochini wrote:

> > As the jmp_buf is a different size in Altivec and non-Altivec code
>
> Because with Altivec we need to save V registers, right ?  Well, I suppose
> intel developers had the same problem with P-III "vector" unit. How did they
> solve the problem ?

As far as I can tell, by ignoring it, and making the assumption that
only low-level libraries will use the vector registers.  I plan to take
a similar approach, and warn users not to mix Altivec and exceptions.

> > To add to the problem, throwing exceptions on an error is just what a
> > modern C++ library is supposed to do.  Throwing or catching an exception
> > in Altivec code will produce sequences that cannot execute on a G3
>
> Why ?? (sorry for my ignorance...)

I haven't studied GCC's implementation of exceptions in great detail.
The compiler saves and restores all the non-transient registers as part
of the exception sequence. When generating Altivec code this produces
stvx and lvx instructions, which will cause an illegal instruction
exception on G3 processors.

- Adrian Cox

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Altivec and binary compatibility

[Giuliano Pochini]

> > Because with Altivec we need to save V registers, right ?  Well, I suppose
> > intel developers had the same problem with P-III "vector" unit. How did they
> > solve the problem ?
>
> As far as I can tell, by ignoring it, and making the assumption that
> only low-level libraries will use the vector registers.

mm :-/

> I plan to take
> a similar approach, and warn users not to mix Altivec and exceptions.

>From altivec p. e. m.: "1.2.6 - The AltiVec vector unit never generates an
exception"

I just started to read the book, but I think AltiVec tells nothing even on
things like divisions by 0, etc.

> > > To add to the problem, throwing exceptions on an error is just what a
> > > modern C++ library is supposed to do.  Throwing or catching an exception
> > > in Altivec code will produce sequences that cannot execute on a G3
> >
> > Why ?? (sorry for my ignorance...)
>
> I haven't studied GCC's implementation of exceptions in great detail.
> The compiler saves and restores all the non-transient registers as part
> of the exception sequence. When generating Altivec code this produces
> stvx and lvx instructions, which will cause an illegal instruction
> exception on G3 processors.

Ok, the programmmer will have to check for AltiVec at the beginning of the
program. What's really important is that programs compiled for 603, 604, G3,
will work fine on G4.

Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Altivec and binary compatibility

[Adrian Cox]

Giuliano Pochini wrote:

> From altivec p. e. m.: "1.2.6 - The AltiVec vector unit never generates an
> exception"
>
> I just started to read the book, but I think AltiVec tells nothing even on
> things like divisions by 0, etc.

C++ exceptions, not machine exceptions:

   if (failure()) thow Oops();\x13

- Adrian Cox, AG Electronics

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Altivec and binary compatibility

[Giuliano Pochini]

> >    This is not correct.  OS's on P-III have to be updated to provide proper
> > context switch support for the SSE registers.  I'm pretty sure Win98 has it
> > covered.  It's really the same type of jump as AltiVec - use of SSE
> > features is not restricted to OS or driver code, apps use them too.
>
> I know that the OS has to support these registers. Latest development
> kernels *DO* support them.
>
> That is not the problem.
>
> The problem is with C++ exception sequences and setjmp being different
> for Altivec and non-Altivec code.

IMHO C++ exceptions are not a problem. All objects are destroyed when a
function exits with an exception and it's an exit without return. The thrown
object is put on the stack (I think) and the calling code will handle it.
Obviously you can't mix code compiled for Altivec and code compiled for plain
PPC if they exchange data with exceptions, jumps and friends.

> How does Linux on ia32 handle linking between generic ia32 and Pentium-III user-space code ?

No idea... It's likely an unsolved issue yet.

Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Altivec and binary compatibility

[Giuliano Pochini]

> >    This is not correct.  OS's on P-III have to be updated to provide proper
> > context switch support for the SSE registers.  I'm pretty sure Win98 has it
> > covered.  It's really the same type of jump as AltiVec - use of SSE
> > features is not restricted to OS or driver code, apps use them too.
>
> I know that the OS has to support these registers. Latest development
> kernels *DO* support them.
>
> That is not the problem.
>
> The problem is with C++ exception sequences and setjmp being different
> for Altivec and non-Altivec code.

IMHO C++ exceptions are not a problem. All objects are destroyed when a
function exits with an exception and it's an exit without return. The thrown
object is put on the stack (I think) and the calling code will handle it.
Obviously you can't mix code compiled for Altivec and code compiled for plain
PPC if they exchange data with exceptions, jumps and friends.

> How does Linux on ia32 handle linking between generic ia32 and Pentium-III user-space code ?

No idea... It's likely an unsolved issue yet.

Bye.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/