From owner-freebsd-sparc Tue Dec 16 17:11:43 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA19002 for sparc-outgoing; Tue, 16 Dec 1997 17:11:43 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA18970 for ; Tue, 16 Dec 1997 17:11:16 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id LAA27621; Wed, 17 Dec 1997 11:40:54 +1030 (CST) (envelope-from grog) Message-ID: <19971217114053.51947@lemis.com> Date: Wed, 17 Dec 1997 11:40:53 +1030 From: Greg Lehey To: freebsd-sparc@FreeBSD.ORG Subject: Re: Data types (was: Re: FAQ FreeBSD-Sparc [frequent posting]) References: <199712162326.AAA13925@dorifer.heim3.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199712162326.AAA13925@dorifer.heim3.tu-clausthal.de>; from Oliver Fromme on Wed, Dec 17, 1997 at 12:26:34AM +0100 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 17, 1997 at 12:26:34AM +0100, Oliver Fromme wrote: > In list.freebsd-sparc perhaps@yes.no wrote: >>> Assumptions about the size of int will need fixed. >> >> OK, what assumptions are correct on UltraSPARC? (Here comes a set of >> possible assumptions; could you try to say which are wrong, and I'll >> try to fix the places where some of them occur?) >> [...] > > On DEC Alpha (at least with DEC's cc), the following is true: > - sizeof(short) == 2 > - sizeof(int) == 4 > - sizeof(long) == 8 > - sizeof(void*) == 8 > Which is a good choice, IMHO. I don't think it is a problem to > have sizeof(int) != sizeof(void*), at least I haven't had any > problems with that on Alphas. Software which assumes that ints > and pointers are of equal size is broken anyway. > > On the other hand, I don't know how efficient it is to access > 32 bit units on the UltraSparc, compared to 64 bit units. > If 32 bit accesses involve a penalty (especially if they are > not 64-bit-aligned), it might be worth to use sizeof(int) = > sizeof(long) = 8. Agreed on both points. But doesn't it make more sense to see how Solaris 2/SunOS 5 defines them? > Is there a special version of gcc for UltraSparc? If so, we > will have to use its idea of the data type sizes, I'm afraid, > so there's no choice. Sure there is. You can always modify it. But without an excellent reason, I don't think it's a good idea to change things from the way other operating systems on the same platform do it. Greg