From owner-freebsd-sparc Sun Dec 21 00:19:01 1997 Return-Path: <owner-freebsd-sparc@FreeBSD.ORG> Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA17084 for sparc-outgoing; Sun, 21 Dec 1997 00:19:01 -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 AAA17053 for <freebsd-sparc@FreeBSD.ORG>; Sun, 21 Dec 1997 00:18:28 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id SAA00966; Sun, 21 Dec 1997 18:48:11 +1030 (CST) (envelope-from grog) Message-ID: <19971221184811.36599@lemis.com> 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]) References: <Pine.UW2.3.96.971217112456.2479J-100000@fatlady.controlq.com> <Pine.BSF.3.96.971217094115.7374n-100000@paladio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <Pine.BSF.3.96.971217094115.7374n-100000@paladio>; from Jason Evans on Sat, Dec 20, 1997 at 11:40:55PM -0800 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 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