From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17808 invoked by alias); 28 Nov 2001 03:00:35 -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 17771 invoked from network); 28 Nov 2001 03:00:32 -0000 Received: from unknown (HELO mail.wrs.com) (147.11.1.11) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 03:00:32 -0000 Received: from kankakee.wrs.com (kankakee [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA16449; Tue, 27 Nov 2001 18:59:10 -0800 (PST) From: mike stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.3+Sun/8.9.0) id SAA10245; Tue, 27 Nov 2001 18:59:52 -0800 (PST) Date: Tue, 20 Nov 2001 11:07:00 -0000 Message-Id: <200111280259.SAA10245@kankakee.wrs.com> To: rth@redhat.com, shebs@apple.com Subject: Re: front end changes for altivec Cc: aldyh@redhat.com, gcc@gcc.gnu.org, jsm28@cam.ac.uk X-SW-Source: 2001-11/txt/msg00956.txt.bz2 > Date: Tue, 27 Nov 2001 14:50:22 -0800 > From: Stan Shebs > To: Richard Henderson > You mean like how we don't have machine-dependent sizes for int > and long int? If in the end we have a portable thing that users can use in a fairly simple and straight forward way, that allows them to switch from a mmx machine to an sse machine, to an sse2 machine, to a ... machine, we win. A good design is also forward compatible with strange hardware that might come up in the future, or strange new operations... On a good number of machines, almost all that matter, int is 32 bits, long int is 32 bits. I can't help but wonder if C would have been a better standard, if they had just outright said, ints are 32 bits, period. It would have removed one major source of confusion and increased (in a theoretical sense only) the portability of user code. I can't help but think that code that does: vector a, b; int foo() { a += b; } is intrinsically better than vector a, b; int foo() { a += b; } We can engineer gcc to have the first work on all machines, quickly on some, `normal' speed on the rest. C++ people, don't let the second confuse you into thinking of std::vector, it is totally different. Think gnu::gcc::vector. In reading code like: vector a, b; int foo() { a += b; } I can say, wow, someone has an arm core with a beefy vector unit attached on an ASIC and I bet this puppy smokes. I can also know that I could compile it up as portable C code, and it would run on anything GNU C supports, though, I might want a faster box in the end (bearing in mind that sizeof(int)==4). From mboxrd@z Thu Jan 1 00:00:00 1970 From: mike stump To: rth@redhat.com, shebs@apple.com Cc: aldyh@redhat.com, gcc@gcc.gnu.org, jsm28@cam.ac.uk Subject: Re: front end changes for altivec Date: Tue, 27 Nov 2001 19:00:00 -0000 Message-ID: <200111280259.SAA10245@kankakee.wrs.com> X-SW-Source: 2001-11/msg01457.html Message-ID: <20011127190000.5vukXQS0P_DLmpf_jMSLcnZq2fOuQawe1HQfb4E6q2g@z> > Date: Tue, 27 Nov 2001 14:50:22 -0800 > From: Stan Shebs > To: Richard Henderson > You mean like how we don't have machine-dependent sizes for int > and long int? If in the end we have a portable thing that users can use in a fairly simple and straight forward way, that allows them to switch from a mmx machine to an sse machine, to an sse2 machine, to a ... machine, we win. A good design is also forward compatible with strange hardware that might come up in the future, or strange new operations... On a good number of machines, almost all that matter, int is 32 bits, long int is 32 bits. I can't help but wonder if C would have been a better standard, if they had just outright said, ints are 32 bits, period. It would have removed one major source of confusion and increased (in a theoretical sense only) the portability of user code. I can't help but think that code that does: vector a, b; int foo() { a += b; } is intrinsically better than vector a, b; int foo() { a += b; } We can engineer gcc to have the first work on all machines, quickly on some, `normal' speed on the rest. C++ people, don't let the second confuse you into thinking of std::vector, it is totally different. Think gnu::gcc::vector. In reading code like: vector a, b; int foo() { a += b; } I can say, wow, someone has an arm core with a beefy vector unit attached on an ASIC and I bet this puppy smokes. I can also know that I could compile it up as portable C code, and it would run on anything GNU C supports, though, I might want a faster box in the end (bearing in mind that sizeof(int)==4).