From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12812 invoked by alias); 18 Dec 2001 02:33:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 12791 invoked from network); 18 Dec 2001 02:33:49 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 18 Dec 2001 02:33:49 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id E7CB2F28BD; Mon, 17 Dec 2001 21:33:48 -0500 (EST) From: dewar@gnat.com To: guerby@acm.org, torvalds@transmeta.com Subject: Re: Big-endian Gcc on Intel IA32 Cc: dewar@gnat.com, gcc@gcc.gnu.org Message-Id: <20011218023348.E7CB2F28BD@nile.gnat.com> Date: Mon, 17 Dec 2001 18:39:00 -0000 X-SW-Source: 2001-12/txt/msg00966.txt.bz2 > 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.