Date: Wed, 17 Dec 1997 11:40:53 +1030 From: Greg Lehey <grog@lemis.com> To: freebsd-sparc@FreeBSD.ORG Subject: Re: Data types (was: Re: FAQ FreeBSD-Sparc [frequent posting]) Message-ID: <19971217114053.51947@lemis.com> In-Reply-To: <199712162326.AAA13925@dorifer.heim3.tu-clausthal.de>; from Oliver Fromme on Wed, Dec 17, 1997 at 12:26:34AM %2B0100 References: <199712162326.AAA13925@dorifer.heim3.tu-clausthal.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971217114053.51947>