Date: Sun, 21 Dec 1997 18:48:11 +1030 From: Greg Lehey <grog@lemis.com> To: Jason Evans <jasone@canonware.com> Cc: "Robert S. Sciuk" <rob@ControlQ.com>, Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de>, freebsd-sparc@FreeBSD.ORG Subject: Re: Data types (was: Re: FAQ FreeBSD-Sparc [frequent posting]) Message-ID: <19971221184811.36599@lemis.com> In-Reply-To: <Pine.BSF.3.96.971217094115.7374n-100000@paladio>; from Jason Evans on Sat, Dec 20, 1997 at 11:40:55PM -0800 References: <Pine.UW2.3.96.971217112456.2479J-100000@fatlady.controlq.com> <Pine.BSF.3.96.971217094115.7374n-100000@paladio>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 20, 1997 at 11:40:55PM -0800, Jason Evans wrote: > > As for the UltraSPARC, I've been having a hard time finding info on the > efficiency of 32 vs 64 bit integer operations. This is of course an > issue, but I think that industry standards should take precedence over the > particulars of the UltraSPARC in this decision, simply because FreeBSD > could be an oddball otherwise. > > ... > > I've read through these web pages, as well as following the discussion > that ensued here. My feeling is that we should go with LP-64 (char --> 8, > short --> 16, int --> 32, long --> 64, pointer --> 64). This seems to me > the most useful from a programming perspective, and it also appears to be > the up and coming standard way of doing things. Like I said before, we > wouldn't be throwing away functionality by choosing this. This sounds like a good a priori approach, though it will cause problems where people assume sizeof (int) == sizeof (void *). But surely you should be able to find somebody under the Sun umbrella who can tell you what Solaris is planning to do for the UltraSPARC. I suppose this would apply to the question of register saving too. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971221184811.36599>