Re: [RFA] W.I.P. AltiVec ppc registers support.

[Andrew Cagney <ac131313@cygnus.com>]

>> >
>> >
>> >How does it work?  Badly.
>> >
>> >The types look like this right now:
>> >
>> >+typedef unsigned char elf_greg_t[4];
>> >+typedef unsigned char elf_fpreg_t[8];
>> >+typedef struct {
>> >+  unsigned char u[16];
>> >+} __attribute((aligned(16))) __uint128_t;
>> >+/* Altivec registers */
>> >+typedef __uint128_t elf_vrreg_t;
> 
>> 
>> Hmm, Kevin did have good reason to be concerned.  That is wrong. 
>> Mechanisms similar to shlib et.al. should be used.
> 
> 
> What is wrong with it?
> 
> I agree that it is messy, but it is completely correct.  I know of no
> platform with 8-bit bytes stupid enough to do this any way other than
> the way I intend.

Several things come to mind: the __attribute() - there are alignment 
independant functions for packing/unpacking/copying stuff; the 
__unint128_t is is a name in system space.

The shlib code does this by describing the actual layout using a very 
thin interface (like how remote.c unpacks the g-packet) so host issues 
aren't a problem (but yes, it would be a suprise to find one that didn't 
have 8 bit chars).

The other way of doing this is more like C++ where it creates a ``struct 
type'' to describe the structure exactly how the target sees it.

enjoy,
Andrew