Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: Extremely Fast Filesystems
Message-ID: <3530@goanna.cs.rmit.oz.au>
Date: 9 Aug 90 06:16:23 GMT
References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <1990Aug8.042631.7093@nlm.nih.gov>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 20

In article <1990Aug8.042631.7093@nlm.nih.gov>, usenet@nlm.nih.gov (usenet news poster) writes:
> Setting aside address arithmatic,
> most of the time you don't need 32 bit integers and lots of work involves
> bytes or smaller (character strings etc.).

For character strings, note that ANSI C's wchar_t type is already bigger
than a byte, and that this is driven by user demand (for Kanji), and that
the ISO 10646 standard which is currently under development encodes
characters in *32* bits.  (I do hope that ISO 10646 will include the
cuneiform characters, they've room for them, after all...)

Given that COBOL requires support for a minimum 18 decimal digits,
64 bits sounds just about right for "ordinary" programs.

For several years I had the pleasure of using a machine with 40 bit
integers (39 bits of magnitude, 1 bit of sign, in a 48-bit word) and
somehow it was never _quite_ enough.  Give people 64 bits and they'll
use them, don't you worry about that.
-- 
Taphonomy begins at death.