Date: Sat, 20 Dec 1997 23:40:55 -0800 (PST) From: Jason Evans <jasone@canonware.com> To: "Robert S. Sciuk" <rob@ControlQ.com> Cc: 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: <Pine.BSF.3.96.971217094115.7374n-100000@paladio> In-Reply-To: <Pine.UW2.3.96.971217112456.2479J-100000@fatlady.controlq.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Dec 1997, Robert S. Sciuk wrote: > On Wed, 17 Dec 1997, Oliver Fromme wrote: > > So the question is: 32 or 64 bits for ints? I think the > > answer depends on how efficient 32-bit accesses (possibly not > > 64-bit-aligned) are one the UltraSparc, as I mentioned in my > > previous posting. > > It is critical to provide full access to the > h/w capabilities (eg: not run a 32Bit OS on 64Bit HW like NT/Alpha), while > allowing the potential for compatability with 32Bit HW -- and moreover to > preserve the portability of existing software!!. 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. Ultimately, it doesn't seem to me that using 32 bit ints could possibly be debilitating, sinces longs will be 64 bits no matter what, which gives full access to 64 bit ints. We're really asking if we want to throw away a capability, and it seems to me way too early in the evolution of 64 bits machines to do so. > http://www.UNIX-systems.org/version2/whatsnew/datasize.html > > and ... > > http://www.UNIX-systems.org/version2/whatsnew/lp64_wp.html 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. Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Work phone: [(408) 774-8007] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971217094115.7374n-100000>