This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Compiling GCC with g++: a report


DJ Delorie <dj@redhat.com> writes:

| >    (2) When and if you switch to this:
| > 
| >         class machine_mode
| >         {
| >           enum value_t {
| >            VOIDmode, SImode, // ...
| >           } value;
| > 
| >          // accessors, whatever ...
| >         };
| 
| I think what Mark wants is to migrate to this:
| 
| 	class machine_mode_desc
| 	{
| 	  unsigned char bits;
| 	  unsigned char is_signed:1;
| 	  unsigned char partial_bits;
| 	  unsigned char vector_width;
| 	  char *name;
| 	  // accessors, whatever
| 	};
| 	class machine_mode
| 	{
| 	  machine_mode_desc *mode_data;
| 	  // various constructors
| 	}
| 
| And the target can do this in tm.c:
| 
| 	class machine_mode SImode ("SI", 32);
| 	class machine_mode V4QImode ("V4QI", 8, 0, 8, 4);
| 
| Then, the MI parts can obtain a mode with certain characteristics,
| enumerate available modes, and get info about a given mode, but don't
| have a compile-time identifier for a "well-known named" mode.

I like it.

However, that is orthogonal to changing the plain numeric value "0" to
the named constant with current machinery, don't you believe?

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]