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: Big-endian Gcc on Intel IA32


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. ;-)


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