This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Big-endian Gcc on Intel IA32
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: dewar at gnat dot com
- Cc: gcc at gcc dot gnu dot org, torvalds at transmeta dot com
- Date: Sun, 23 Dec 2001 16:04:54 +0100
- Subject: Re: Big-endian Gcc on Intel IA32
- References: <20011218113556.BCF65F28BD@nile.gnat.com>
dewar@gnat.com writes:
> 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.
This probably indicates a bug in the problem, so the compiler should
reject it.
> Here is another problem, do you want to allow non-contiguous fields
> in the case of bit field specifications.
Hmm, I assume that this is part of the solution of the general
case. ;-)
> Yes, it is possible that you can find a restricted set of cases you
> can deal with at the struct level,
I wouldn't tackle this problem at the struct level, but at the
discrete type level, IOW introduce additional integer types with
different resentation. This would already greatly help in many cases.
> but Florian's suggestion that the only restriction necessary is 2-s
> complement (what's that got to do with the problem???)
If you've got signed-magnitude representation, you've got plenty of
positions in which you can place the sign bit.
> 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)
If the machine is word-adressed, all we do in this regard won't help
much to increase portability because a lot of data structures with a
given external representation assume you can access individual octets,
and the mapping to a useful machine implementation is certainly not
straightforward. For example, how does an IP header look on a 36 bit
machine?
> is flawed.
Maybe. ;-)