From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-114901-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6146 invoked by alias); 25 May 2005 01:12:40 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 6102 invoked by uid 22791); 25 May 2005 01:12:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 25 May 2005 01:12:34 +0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4P1CW6r027158;
	Tue, 24 May 2005 21:12:32 -0400
Received: from post-office.corp.redhat.com (post-office.corp.redhat.com [172.16.52.227])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4P1CWO05206;
	Tue, 24 May 2005 21:12:32 -0400
Received: from greed.delorie.com (dj.cipe.redhat.com [10.0.0.222])
	by post-office.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4P1CVv11446;
	Tue, 24 May 2005 21:12:32 -0400
Received: from greed.delorie.com (greed.delorie.com [127.0.0.1])
	by greed.delorie.com (8.13.1/8.13.1) with ESMTP id j4P1CVIT029977;
	Tue, 24 May 2005 21:12:31 -0400
Received: (from dj@localhost)
	by greed.delorie.com (8.13.1/8.13.1/Submit) id j4P1CQ0A029974;
	Tue, 24 May 2005 21:12:26 -0400
Date: Wed, 25 May 2005 01:47:00 -0000
Message-Id: <200505250112.j4P1CQ0A029974@greed.delorie.com>
From: DJ Delorie <dj@redhat.com>
To: gdr@integrable-solutions.net
CC: gcc@gcc.gnu.org
In-reply-to: <m3fywcxe0z.fsf@uniton.integrable-solutions.net> (message from
	Gabriel Dos Reis on 25 May 2005 03:58:20 +0200)
Subject: Re: Compiling GCC with g++: a report
References: <m364xapix6.fsf@merlin.cs.tamu.edu>
	<1116907280.9577.31.camel@localhost.localdomain>
	<m3k6lp17iv.fsf@uniton.integrable-solutions.net>
	<87br71kv04.fsf@codesourcery.com>
	<m37jhpt5gn.fsf@uniton.integrable-solutions.net>
	<87y8a5je22.fsf@codesourcery.com>
	<m3fywdqa89.fsf@uniton.integrable-solutions.net>
	<1116976014.8637.11.camel@localhost.localdomain>
	<m3oeb03ymf.fsf@uniton.integrable-solutions.net>
	<1116979946.8798.4.camel@localhost.localdomain> <m3fywcxe0z.fsf@uniton.integrable-solutions.net>
X-SW-Source: 2005-05/txt/msg01339.txt.bz2


>    (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.