From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-43045-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 3037 invoked by alias); 18 Dec 2001 11:36:09 -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 2992 invoked from network); 18 Dec 2001 11:35:58 -0000
Received: from unknown (HELO nile.gnat.com) (205.232.38.5)
  by sources.redhat.com with SMTP; 18 Dec 2001 11:35:58 -0000
Received: by nile.gnat.com (Postfix, from userid 338)
	id BCF65F28BD; Tue, 18 Dec 2001 06:35:56 -0500 (EST)
From: dewar@gnat.com
To: dewar@gnat.com, fw@deneb.enyo.de
Subject: Re: Big-endian Gcc on Intel IA32
Cc: gcc@gcc.gnu.org, torvalds@transmeta.com
Message-Id: <20011218113556.BCF65F28BD@nile.gnat.com>
Date: Tue, 18 Dec 2001 03:49:00 -0000
X-SW-Source: 2001-12/txt/msg00981.txt.bz2

<<Yes, in the general case, this is of course right.  But for two's
complement, octet-adressed machines, endian representation clauses for
discrete types could be implemented without major problems, I think,
at least if you restrict yourself to the little/big endian case and
ignore PDP endian.
>>

I will just give one example of a problem. What do you do with a type
which is a union, one branch of which is a four byte integer, the other
branch is two two-byte integers. Here is another problem, do you want
to allow non-contiguous fields in the case of bit field specifications.
Again, I refer people to the Norm Cohen paper on this subject. Yes, it
is possible that you can find a restricted set of cases you can deal
with at the struct level, but Florian's suggestion that the only
restriction necessary is 2-s complement (what's that got to do with
the problem???) and octet-addressed machines (what's that got to do with
the problem--it's easier to deal with this problem on word addressed machines)
is flawed.