From owner-freebsd-sparc Sat Dec 20 23:41:46 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA14778 for sparc-outgoing; Sat, 20 Dec 1997 23:41:46 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from mozart.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA14773 for ; Sat, 20 Dec 1997 23:41:40 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by mozart.canonware.com (8.8.7/8.8.7) with SMTP id XAA00785; Sat, 20 Dec 1997 23:40:55 -0800 (PST) (envelope-from jasone@canonware.com) X-Authentication-Warning: mozart.canonware.com: jasone owned process doing -bs Date: Sat, 20 Dec 1997 23:40:55 -0800 (PST) From: Jason Evans Reply-To: Jason Evans To: "Robert S. Sciuk" cc: Oliver Fromme , freebsd-sparc@FreeBSD.ORG Subject: Re: Data types (was: Re: FAQ FreeBSD-Sparc [frequent posting]) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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]