RFC: Add 'double' member to 64-bit vector register type

RFC: Add 'double' member to 64-bit vector register type

[Jim Blandy]

gdb/ChangeLog:
2005-03-17  Jim Blandy  <jimb@redhat.com>

	* gdbtypes.c (build_builtin_type_vec64): Include a 'double' member
	in the union, too, since these registers can hold 64-bit floating
	point types.

gdb/testsuite/ChangeLog:
2005-03-17  Jim Blandy  <jimb@redhat.com>

	* gdb.arch/e500-regs.exp: Expect to see 'dbl' members in ev
	registers.

Index: gdb/gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.99
diff -c -p -r1.99 gdbtypes.c
*** gdb/gdbtypes.c	24 Feb 2005 13:51:32 -0000	1.99
--- gdb/gdbtypes.c	17 Mar 2005 05:19:43 -0000
*************** build_builtin_type_vec64 (void)
*** 896,901 ****
--- 896,902 ----
    union __gdb_builtin_type_vec64
    {
      int64_t uint64;
+     double dbl;
      float v2_float[2];
      int32_t v2_int32[2];
      int16_t v4_int16[4];
*************** build_builtin_type_vec64 (void)
*** 907,912 ****
--- 908,914 ----
  
    t = init_composite_type ("__gdb_builtin_type_vec64", TYPE_CODE_UNION);
    append_composite_type_field (t, "uint64", builtin_type_int64);
+   append_composite_type_field (t, "dbl", builtin_type_double);
    append_composite_type_field (t, "v2_float", builtin_type_v2_float);
    append_composite_type_field (t, "v2_int32", builtin_type_v2_int32);
    append_composite_type_field (t, "v4_int16", builtin_type_v4_int16);
Index: gdb/testsuite/gdb.arch/e500-regs.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.arch/e500-regs.exp,v
retrieving revision 1.2
diff -c -p -r1.2 e500-regs.exp
*** gdb/testsuite/gdb.arch/e500-regs.exp	15 Jun 2004 18:12:04 -0000	1.2
--- gdb/testsuite/gdb.arch/e500-regs.exp	17 Mar 2005 05:19:47 -0000
*************** gdb_expect {
*** 85,93 ****
  # b) the register read (below) also works.
  
  if {$endianness == "big"} {
! set vector_register ".uint64 = 0x100000001, v2_float = .0x0, 0x0., v2_int32 = .0x1, 0x1., v4_int16 = .0x0, 0x1, 0x0, 0x1., v8_int8 = .0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x1.."
  } else {
! set vector_register ".uint64 = 0x100000001, v2_float = .0x0, 0x0., v2_int32 = .0x1, 0x1., v4_int16 = .0x1, 0x0, 0x1, 0x0., v8_int8 = .0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0.."
  }
  
  for {set i 0} {$i < 32} {incr i 1} {
--- 85,93 ----
  # b) the register read (below) also works.
  
  if {$endianness == "big"} {
! set vector_register ".uint64 = 0x100000001, dbl = 0x0, v2_float = .0x0, 0x0., v2_int32 = .0x1, 0x1., v4_int16 = .0x0, 0x1, 0x0, 0x1., v8_int8 = .0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x1.."
  } else {
! set vector_register ".uint64 = 0x100000001, dbl = 0x0, v2_float = .0x0, 0x0., v2_int32 = .0x1, 0x1., v4_int16 = .0x1, 0x0, 0x1, 0x0., v8_int8 = .0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0.."
  }
  
  for {set i 0} {$i < 32} {incr i 1} {
*************** for {set i 0} {$i < 32} {incr i 1} {
*** 110,118 ****
  # the way gdb works.
  
  if {$endianness == "big"} {
!      set decimal_vector ".uint64 = 4294967297, v2_float = .1.*e-45, 1.*e-45., v2_int32 = .1, 1., v4_int16 = .0, 1, 0, 1., v8_int8 = ..000.000.000.001.000.000.000.001.."
  } else {
!      set decimal_vector ".uint64 = 4294967297, v2_float = .1.*e-45, 1.*e-45., v2_int32 = .1, 1., v4_int16 = .1, 0, 1, 0., v8_int8 = ..001.000.000.000.001.000.000.."
  }
  
  for {set i 0} {$i < 32} {incr i 1} {
--- 110,118 ----
  # the way gdb works.
  
  if {$endianness == "big"} {
!      set decimal_vector ".uint64 = 4294967297, dbl = 0, v2_float = .1.*e-45, 1.*e-45., v2_int32 = .1, 1., v4_int16 = .0, 1, 0, 1., v8_int8 = ..000.000.000.001.000.000.000.001.."
  } else {
!      set decimal_vector ".uint64 = 4294967297, dbl = 0, v2_float = .1.*e-45, 1.*e-45., v2_int32 = .1, 1., v4_int16 = .1, 0, 1, 0., v8_int8 = ..001.000.000.000.001.000.000.."
  }
  
  for {set i 0} {$i < 32} {incr i 1} {

Re: RFC: Add 'double' member to 64-bit vector register type

[Daniel Jacobowitz]

On Sat, Mar 19, 2005 at 01:13:15AM -0500, Jim Blandy wrote:
> 
> gdb/ChangeLog:
> 2005-03-17  Jim Blandy  <jimb@redhat.com>
> 
> 	* gdbtypes.c (build_builtin_type_vec64): Include a 'double' member
> 	in the union, too, since these registers can hold 64-bit floating
> 	point types.

Rationale belongs in the patch mail or in comments, not in the
changelog.

I suppose you might as well, since no one but the e500 uses them.  But
only some SPE processors support the double precision mode; do you
really want to display the register as double on e500 v1?


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: Add 'double' member to 64-bit vector register type

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> On Sat, Mar 19, 2005 at 01:13:15AM -0500, Jim Blandy wrote:
> > 
> > gdb/ChangeLog:
> > 2005-03-17  Jim Blandy  <jimb@redhat.com>
> > 
> > 	* gdbtypes.c (build_builtin_type_vec64): Include a 'double' member
> > 	in the union, too, since these registers can hold 64-bit floating
> > 	point types.
> 
> Rationale belongs in the patch mail or in comments, not in the
> changelog.

D'oh.  Thanks; I'll move it.

> I suppose you might as well, since no one but the e500 uses them.  But
> only some SPE processors support the double precision mode; do you
> really want to display the register as double on e500 v1?

Well, that brings up the other thought --- since the set of types
useful to include in a vector register really depends on the
architecture, wouldn't it be better to just export the convenience
functions for constructing these types from gdbtypes.c and then let
architectures build ones that actually suit their needs?

Re: RFC: Add 'double' member to 64-bit vector register type

[Daniel Jacobowitz]

On Sat, Mar 19, 2005 at 04:13:12PM -0500, Jim Blandy wrote:
> Well, that brings up the other thought --- since the set of types
> useful to include in a vector register really depends on the
> architecture, wouldn't it be better to just export the convenience
> functions for constructing these types from gdbtypes.c and then let
> architectures build ones that actually suit their needs?

My inclination is "yes".  Anybody else?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: Add 'double' member to 64-bit vector register type

[Mark Kettenis]

   Date: Sat, 19 Mar 2005 21:33:07 -0500
   From: Daniel Jacobowitz <drow@false.org>

   On Sat, Mar 19, 2005 at 04:13:12PM -0500, Jim Blandy wrote:
   > Well, that brings up the other thought --- since the set of types
   > useful to include in a vector register really depends on the
   > architecture, wouldn't it be better to just export the convenience
   > functions for constructing these types from gdbtypes.c and then let
   > architectures build ones that actually suit their needs?

   My inclination is "yes".  Anybody else?

I agree.

Mark

Re: RFC: Add 'double' member to 64-bit vector register type

[Jim Blandy]

Mark Kettenis <mark.kettenis@xs4all.nl> writes:
>    Date: Sat, 19 Mar 2005 21:33:07 -0500
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    On Sat, Mar 19, 2005 at 04:13:12PM -0500, Jim Blandy wrote:
>    > Well, that brings up the other thought --- since the set of types
>    > useful to include in a vector register really depends on the
>    > architecture, wouldn't it be better to just export the convenience
>    > functions for constructing these types from gdbtypes.c and then let
>    > architectures build ones that actually suit their needs?
> 
>    My inclination is "yes".  Anybody else?
> 
> I agree.

Getting back to this...

Here's a patch to move the IA-32 vector types out of gdbtypes.h.  The
PowerPC Altivec and SPE types are a little more work, since they
need to be per-architecture, so I'll leave that to a separate patch.

How does this look?

(There really was no DEPRECATED_REGISTER_GDBARCH_SWAP entry for
builtin_type_vec64i.)

2005-04-05  Jim Blandy  <jimb@redhat.com>

	Move construction of IA-32 vector types to i386-tdep.c.
	* gdbtypes.c (build_builtin_type_vec64i,
	build_builtin_type_vec128i): Delete functions.
	(builtin_type_vec64i, builtin_type_vec128i): Delete variables.
	(build_gdbtypes): Don't initialize them.
	(_initialize_gdbtypes): Don't register GDBARCH swap entries for
	them.
	* gdbtypes.h (builtin_type_vec64i, builtin_type_vec128i): Delete
	declarations.
	(builtin_type_v2_float, builtin_type_v2_int32,
	builtin_type_v4_int16, builtin_type_v8_int8,
	builtin_type_v2_double, builtin_type_v4_float,
	builtin_type_v2_int64, builtin_type_v4_int32,
	builtin_type_v8_int16, builtin_type_v16_int8): Add extern
	declarations.
	* i386-tdep.c (i386_mmx_type, i386_sse_type): New variables.
	(i386_build_mmx_type, i386_build_sse_type): New functions.
	(i386_register_type): Call them, rather than referring to
	builtin_type_vec64i and builtin_type_vec128i.

Index: gdb/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.7055
diff -c -p -r1.7055 ChangeLog
*** gdb/ChangeLog	2 Apr 2005 22:59:16 -0000	1.7055
--- gdb/ChangeLog	5 Apr 2005 15:48:43 -0000
***************
*** 64,69 ****
--- 64,91 ----
  	* Makefile.in (alpha-linux-tdep.o, ia64-linux-tdep.o)
  	(sparc-linux-tdep.o): Update dependencies.
  
+ 2005-03-29  Jim Blandy  <jimb@redhat.com>
+ 
+ 	Move construction of IA-32 vector types to i386-tdep.c.
+ 	* gdbtypes.c (build_builtin_type_vec64i,
+ 	build_builtin_type_vec128i): Delete functions.
+ 	(builtin_type_vec64i, builtin_type_vec128i): Delete variables.
+ 	(build_gdbtypes): Don't initialize them.
+ 	(_initialize_gdbtypes): Don't register GDBARCH swap entries for
+ 	them.
+ 	* gdbtypes.h (builtin_type_vec64i, builtin_type_vec128i): Delete
+ 	declarations.
+ 	(builtin_type_v2_float, builtin_type_v2_int32,
+ 	builtin_type_v4_int16, builtin_type_v8_int8,
+ 	builtin_type_v2_double, builtin_type_v4_float,
+ 	builtin_type_v2_int64, builtin_type_v4_int32,
+ 	builtin_type_v8_int16, builtin_type_v16_int8): Add extern
+ 	declarations.
+ 	* i386-tdep.c (i386_mmx_type, i386_sse_type): New variables.
+ 	(i386_build_mmx_type, i386_build_sse_type): New functions.
+ 	(i386_register_type): Call them, rather than referring to
+ 	builtin_type_vec64i and builtin_type_vec128i.
+ 
  2005-03-29  Daniel Jacobowitz  <dan@codesourcery.com>
  
  	* c-valprint.c (c_value_print): Fix up some formatting.  Use
Index: gdb/gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.99
diff -c -p -r1.99 gdbtypes.c
*** gdb/gdbtypes.c	24 Feb 2005 13:51:32 -0000	1.99
--- gdb/gdbtypes.c	5 Apr 2005 15:48:44 -0000
*************** struct type *builtin_type_v8hi;
*** 94,102 ****
  struct type *builtin_type_v4hi;
  struct type *builtin_type_v2si;
  struct type *builtin_type_vec64;
- struct type *builtin_type_vec64i;
  struct type *builtin_type_vec128;
- struct type *builtin_type_vec128i;
  struct type *builtin_type_ieee_single[BFD_ENDIAN_UNKNOWN];
  struct type *builtin_type_ieee_single_big;
  struct type *builtin_type_ieee_single_little;
--- 94,100 ----
*************** build_builtin_type_vec64 (void)
*** 918,951 ****
  }
  
  static struct type *
- build_builtin_type_vec64i (void)
- {
-   /* Construct a type for the 64 bit registers.  The type we're
-      building is this: */
- #if 0
-   union __gdb_builtin_type_vec64i 
-   {
-     int64_t uint64;
-     int32_t v2_int32[2];
-     int16_t v4_int16[4];
-     int8_t v8_int8[8];
-   };
- #endif
- 
-   struct type *t;
- 
-   t = init_composite_type ("__gdb_builtin_type_vec64i", TYPE_CODE_UNION);
-   append_composite_type_field (t, "uint64", builtin_type_int64);
-   append_composite_type_field (t, "v2_int32", builtin_type_v2_int32);
-   append_composite_type_field (t, "v4_int16", builtin_type_v4_int16);
-   append_composite_type_field (t, "v8_int8", builtin_type_v8_int8);
- 
-   TYPE_FLAGS (t) |= TYPE_FLAG_VECTOR;
-   TYPE_NAME (t) = "builtin_type_vec64i";
-   return t;
- }
- 
- static struct type *
  build_builtin_type_vec128 (void)
  {
    /* Construct a type for the 128 bit registers.  The type we're
--- 916,921 ----
*************** build_builtin_type_vec128 (void)
*** 975,1000 ****
    return t;
  }
  
- static struct type *
- build_builtin_type_vec128i (void)
- {
-   /* 128-bit Intel SIMD registers */
-   struct type *t;
- 
-   t = init_composite_type ("__gdb_builtin_type_vec128i", TYPE_CODE_UNION);
-   append_composite_type_field (t, "v4_float", builtin_type_v4_float);
-   append_composite_type_field (t, "v2_double", builtin_type_v2_double);
-   append_composite_type_field (t, "v16_int8", builtin_type_v16_int8);
-   append_composite_type_field (t, "v8_int16", builtin_type_v8_int16);
-   append_composite_type_field (t, "v4_int32", builtin_type_v4_int32);
-   append_composite_type_field (t, "v2_int64", builtin_type_v2_int64);
-   append_composite_type_field (t, "uint128", builtin_type_int128);
- 
-   TYPE_FLAGS (t) |= TYPE_FLAG_VECTOR;
-   TYPE_NAME (t) = "builtin_type_vec128i";
-   return t;
- }
- 
  /* Smash TYPE to be a type of members of DOMAIN with type TO_TYPE. 
     A MEMBER is a wierd thing -- it amounts to a typed offset into
     a struct, e.g. "an int at offset 8".  A MEMBER TYPE doesn't
--- 945,950 ----
*************** Show resolution of opaque struct/class/u
*** 3307,3315 ****
  
    /* Vector types.  */
    builtin_type_vec64 = build_builtin_type_vec64 ();
-   builtin_type_vec64i = build_builtin_type_vec64i ();
    builtin_type_vec128 = build_builtin_type_vec128 ();
-   builtin_type_vec128i = build_builtin_type_vec128i ();
  
    /* Pointer/Address types. */
  
--- 3257,3263 ----
*************** _initialize_gdbtypes (void)
*** 3608,3614 ****
    DEPRECATED_REGISTER_GDBARCH_SWAP (builtin_type_v8_int8);
    DEPRECATED_REGISTER_GDBARCH_SWAP (builtin_type_v4_int16);
    DEPRECATED_REGISTER_GDBARCH_SWAP (builtin_type_vec128);
-   DEPRECATED_REGISTER_GDBARCH_SWAP (builtin_type_vec128i);
    DEPRECATED_REGISTER_GDBARCH_SWAP (builtin_type_void_data_ptr);
    DEPRECATED_REGISTER_GDBARCH_SWAP (builtin_type_void_func_ptr);
    DEPRECATED_REGISTER_GDBARCH_SWAP (builtin_type_CORE_ADDR);
--- 3556,3561 ----
Index: gdb/gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.61
diff -c -p -r1.61 gdbtypes.h
*** gdb/gdbtypes.h	28 Jan 2005 19:03:53 -0000	1.61
--- gdb/gdbtypes.h	5 Apr 2005 15:48:44 -0000
*************** extern struct type *builtin_type_v8hi;
*** 1072,1084 ****
  extern struct type *builtin_type_v4hi;
  extern struct type *builtin_type_v2si;
  
! /* Type for 64 bit vectors. */
  extern struct type *builtin_type_vec64;
- extern struct type *builtin_type_vec64i;
  
! /* Type for 128 bit vectors. */
  extern struct type *builtin_type_vec128;
- extern struct type *builtin_type_vec128i;
  
  /* Explicit floating-point formats.  See "floatformat.h".  */
  extern struct type *builtin_type_ieee_single[BFD_ENDIAN_UNKNOWN];
--- 1072,1092 ----
  extern struct type *builtin_type_v4hi;
  extern struct type *builtin_type_v2si;
  
! /* Types for 64 bit vectors. */
! extern struct type *builtin_type_v2_float;
! extern struct type *builtin_type_v2_int32;
! extern struct type *builtin_type_v4_int16;
! extern struct type *builtin_type_v8_int8;
  extern struct type *builtin_type_vec64;
  
! /* Types for 128 bit vectors. */
! extern struct type *builtin_type_v2_double;
! extern struct type *builtin_type_v4_float;
! extern struct type *builtin_type_v2_int64;
! extern struct type *builtin_type_v4_int32;
! extern struct type *builtin_type_v8_int16;
! extern struct type *builtin_type_v16_int8;
  extern struct type *builtin_type_vec128;
  
  /* Explicit floating-point formats.  See "floatformat.h".  */
  extern struct type *builtin_type_ieee_single[BFD_ENDIAN_UNKNOWN];
Index: gdb/i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.208
diff -c -p -r1.208 i386-tdep.c
*** gdb/i386-tdep.c	21 Feb 2005 04:31:57 -0000	1.208
--- gdb/i386-tdep.c	5 Apr 2005 15:48:45 -0000
*************** i386_return_value (struct gdbarch *gdbar
*** 1489,1494 ****
--- 1489,1561 ----
  }
  \f
  
+ /* Types for the MMX and SSE registers.  */
+ static struct type *i386_mmx_type;
+ static struct type *i386_sse_type;
+ 
+ 
+ /* Construct the type for MMX registers.  */
+ static struct type *
+ i386_build_mmx_type (void)
+ {
+   /* The type we're building is this: */
+ #if 0
+   union __gdb_builtin_type_vec64i 
+   {
+     int64_t uint64;
+     int32_t v2_int32[2];
+     int16_t v4_int16[4];
+     int8_t v8_int8[8];
+   };
+ #endif
+ 
+   if (! i386_mmx_type)
+     {
+       struct type *t;
+ 
+       t = init_composite_type ("__gdb_builtin_type_vec64i", TYPE_CODE_UNION);
+       append_composite_type_field (t, "uint64", builtin_type_int64);
+       append_composite_type_field (t, "v2_int32", builtin_type_v2_int32);
+       append_composite_type_field (t, "v4_int16", builtin_type_v4_int16);
+       append_composite_type_field (t, "v8_int8", builtin_type_v8_int8);
+ 
+       TYPE_FLAGS (t) |= TYPE_FLAG_VECTOR;
+       TYPE_NAME (t) = "builtin_type_vec64i";
+ 
+       i386_mmx_type = t;
+     }
+ 
+   return i386_mmx_type;
+ }
+ 
+ 
+ /* Construct the type for SSE registers.  */
+ static struct type *
+ i386_build_sse_type (void)
+ {
+   if (! i386_sse_type)
+     {
+       struct type *t;
+ 
+       t = init_composite_type ("__gdb_builtin_type_vec128i", TYPE_CODE_UNION);
+       append_composite_type_field (t, "v4_float", builtin_type_v4_float);
+       append_composite_type_field (t, "v2_double", builtin_type_v2_double);
+       append_composite_type_field (t, "v16_int8", builtin_type_v16_int8);
+       append_composite_type_field (t, "v8_int16", builtin_type_v8_int16);
+       append_composite_type_field (t, "v4_int32", builtin_type_v4_int32);
+       append_composite_type_field (t, "v2_int64", builtin_type_v2_int64);
+       append_composite_type_field (t, "uint128", builtin_type_int128);
+ 
+       TYPE_FLAGS (t) |= TYPE_FLAG_VECTOR;
+       TYPE_NAME (t) = "builtin_type_vec128i";
+       
+       i386_sse_type = t;
+     }
+ 
+   return i386_sse_type;
+ }
+ 
+ 
  /* Return the GDB type object for the "standard" data type of data in
     register REGNUM.  Perhaps %esi and %edi should go here, but
     potentially they could be used for things other than address.  */
*************** i386_register_type (struct gdbarch *gdba
*** 1504,1513 ****
      return builtin_type_i387_ext;
  
    if (i386_sse_regnum_p (gdbarch, regnum))
!     return builtin_type_vec128i;
  
    if (i386_mmx_regnum_p (gdbarch, regnum))
!     return builtin_type_vec64i;
  
    return builtin_type_int;
  }
--- 1571,1580 ----
      return builtin_type_i387_ext;
  
    if (i386_sse_regnum_p (gdbarch, regnum))
!     return i386_build_sse_type ();
  
    if (i386_mmx_regnum_p (gdbarch, regnum))
!     return i386_build_mmx_type ();
  
    return builtin_type_int;
  }

Re: RFC: Add 'double' member to 64-bit vector register type

[Mark Kettenis]

   From: Jim Blandy <jimb@redhat.com>
   Date: 05 Apr 2005 11:55:43 -0500

   Mark Kettenis <mark.kettenis@xs4all.nl> writes:
   >    Date: Sat, 19 Mar 2005 21:33:07 -0500
   >    From: Daniel Jacobowitz <drow@false.org>
   > 
   >    On Sat, Mar 19, 2005 at 04:13:12PM -0500, Jim Blandy wrote:
   >    > Well, that brings up the other thought --- since the set of types
   >    > useful to include in a vector register really depends on the
   >    > architecture, wouldn't it be better to just export the convenience
   >    > functions for constructing these types from gdbtypes.c and then let
   >    > architectures build ones that actually suit their needs?
   > 
   >    My inclination is "yes".  Anybody else?
   > 
   > I agree.

   Getting back to this...

   Here's a patch to move the IA-32 vector types out of gdbtypes.h.  The
   PowerPC Altivec and SPE types are a little more work, since they
   need to be per-architecture, so I'll leave that to a separate patch.

   How does this look?

Looks fine to me, except for one nit: can you remove the "excessive"
spacing (one blank line between functions is more than enough,
especially since all the new stuff logically belongs together).

Mark

Re: RFC: Add 'double' member to 64-bit vector register type

[Jim Blandy]

Mark Kettenis <mark.kettenis@xs4all.nl> writes:
>    From: Jim Blandy <jimb@redhat.com>
>    Date: 05 Apr 2005 11:55:43 -0500
> 
>    Mark Kettenis <mark.kettenis@xs4all.nl> writes:
>    >    Date: Sat, 19 Mar 2005 21:33:07 -0500
>    >    From: Daniel Jacobowitz <drow@false.org>
>    > 
>    >    On Sat, Mar 19, 2005 at 04:13:12PM -0500, Jim Blandy wrote:
>    >    > Well, that brings up the other thought --- since the set of types
>    >    > useful to include in a vector register really depends on the
>    >    > architecture, wouldn't it be better to just export the convenience
>    >    > functions for constructing these types from gdbtypes.c and then let
>    >    > architectures build ones that actually suit their needs?
>    > 
>    >    My inclination is "yes".  Anybody else?
>    > 
>    > I agree.
> 
>    Getting back to this...
> 
>    Here's a patch to move the IA-32 vector types out of gdbtypes.h.  The
>    PowerPC Altivec and SPE types are a little more work, since they
>    need to be per-architecture, so I'll leave that to a separate patch.
> 
>    How does this look?
> 
> Looks fine to me, except for one nit: can you remove the "excessive"
> spacing (one blank line between functions is more than enough,
> especially since all the new stuff logically belongs together).

Done, and committed.  Thanks!