Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!ncifcrf!lhc!usenet
From: usenet@nlm.nih.gov (usenet news poster)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <1990Aug22.031911.7376@nlm.nih.gov>
Date: 22 Aug 90 03:19:11 GMT
References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <9660@ganymede.inmos.co.uk> <224@csinc.UUCP> <1263.26cdaecc@waikato.ac.nz> <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <41004@mips.mips.COM>
Reply-To: states@tech.NLM.NIH.GOV (David States)
Organization: National Library of Medicine, Bethesda, Md.
Lines: 19

In article <41004@mips.mips.COM> mash@mips.COM (John Mashey) writes:

    [Why not 48-bit processors?]

>1) Software inertia strongly impels people to build machines whose
>words contain 2**n bytes, for C especially, but also for other languages.
>2) (Some) software inertia and (much) hardware inertia impels people
>to use 8-bit characters.
>3) So, I'd be amazed if a new general-purpose architecture would likely
>be viable at 48 bits.

In scientific work 64-bit floating point has become standard.  Hydrid
processors with some 32 and some 64-bit paths/registers are viable, but
increasing the 32-bit paths to 48 is not going to help much in 64-bit
transfers, and you would still need two 48-bit registers to store one
64-bit number.  Finally, I don't think 48-bit FP could totally replace
64-bit, although it could do alot better than 32-bit FP.

David States