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: dewar at gnat dot com
- To: guerby at acm dot org, torvalds at transmeta dot com
- Cc: dewar at gnat dot com, gcc at gcc dot gnu dot org
- Date: Mon, 17 Dec 2001 21:33:48 -0500 (EST)
- Subject: Re: Big-endian Gcc on Intel IA32
> Too bad about the algol syntax and all the overkill features (hey, I think
> C++ is complex, Ada is so far off the scale that it's not even funny).>
Well this is not the place for language wars, but in practice those who know
Ada well and C++ well typically find then to be languages of similar
complexity (with perhaps a little bias showing one way or the other), but
a judgment that Ada is "so far off the scale" is one that in my experience
only comes from those who do not know Ada well, or even at all (to be fair
there are plenty of Ada folks who say dubious things about C++ without knowing
the language -- it seems to be a regrettable tendency in the programming
language area for people to have strong opinions about languages they don't
know. As a COBOL expert, I encounter that phenomenon all the time :-) :-)
Anyway, as I say, I don't think that this is the place for language wars,
and flame bait statements like the one quoted here :-)
What I *do* think we can usefully do is to learn from useful features in
the various languages, especially when we are discussing adding new features
to an existing language. In this particular case, I would really like to
see GNU C (and g++) implement some of the Ada features in the data
representation area for two reasons:
1. These are really useful in controlling layout of data, and dealing with
such issues as bit order etc.
2. If this handling was in the back end, it would be more efficient, and
would allow us to rip a lot of junk out of the Ada front end.
A candidate is indeed some kind of assistance for handling endianess. What
we did in the Realia COBOL compiler, which certainly is helpful and does
not raise awkward language issues, is to simply define the equivalent of
an attribute that applies to an integral type which says what endianess
it has (in Realia COBOL, COMP-4 was IBM compatible big endian, and COMP-5
was Intel little-endian). That's quite easy to implement as a gcc attribute
and would be very useful. This would avoid getting into the more complex
record layout issues.
Another candidate would be bit packed arrays. In practice this is a very
useful feature. Currently the circuitry for bit packing is in the front end
of the Ada compiler, but it would be nice to move it into the back end so
that other GNU languages could take advantage of it.