Date: Wed, 17 Dec 1997 11:49:51 -0500 (EST) From: "Robert S. Sciuk" <rob@ControlQ.com> To: Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de> Cc: freebsd-sparc@FreeBSD.ORG Subject: Re: Data types (was: Re: FAQ FreeBSD-Sparc [frequent posting]) Message-ID: <Pine.UW2.3.96.971217112456.2479J-100000@fatlady.controlq.com> In-Reply-To: <199712170331.EAA15014@dorifer.heim3.tu-clausthal.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > Personally I'd prefer 32 bits (if there are no efficiency > reasons for 64 bits), because it seems to be more elegant to > me. Then we would have types for all the common sizes: > 8 bits (char), 16 bits (short), 32 bits (int), 64 bits (long). > This is not exactly a technical reason, though (I don't think > that there's software that has problems if there is no 32 bit > type). IMHO, the integer type (int) should be the `natural' integer size for the architecture -- that is, the natural bus/register width, and that which is best represented by instructions to support that datatype. No offence intended, but personal preference should not enter into this decision ... millions of lines of existing code depend upon certain assumptions regarding wordsizes ... it may ultimately require compiler switches, and multiple Clibs (a la' the early intel C compilers -- ugh). Moreover, I recall recently some sort of announcement of FreeBSD offering some degree of single unix compliance (X/Open, or OpenGroup or some such thingy) at some time in the ill-defined future :-). I'm sure that Sun(Soft) has some degree of compliance as well. Whatever decision is made, consideration needs to be given to compliant API's, file sizes, memory addressability, etc. 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!!. Nor should we fail to learn from past mistakes (vendor variations in the 16-32bit transition). A good starting point is the whitepaper referenced below. If the industry at large has agreed to a solution, perhaps we should listen?? http://www.UNIX-systems.org/version2/whatsnew/datasize.html and ... http://www.UNIX-systems.org/version2/whatsnew/lp64_wp.html I hope this is useful. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert S. Sciuk 1032 Howard Rd. Ph:905 632-2466 Control-Q Research Burlington, Ont. Canada Fx:905 632-7417 rob@ControlQ.com L7R 3X5 http://www.ControlQ.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.UW2.3.96.971217112456.2479J-100000>