Xref: utzoo comp.lang.misc:3559 comp.arch:11669
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.lang.misc,comp.arch
Subject: Re: Fast conversions, another urban myth?
Message-ID: <6433@pt.cs.cmu.edu>
Date: 6 Oct 89 15:25:58 GMT
References: <832@dms.UUCP> <688@UALTAVM.BITNET> <1989Sep25.184425.20936@utzoo.uucp> <2261@csadfa.oz>
Organization: Carnegie-Mellon University, CS/RI
Lines: 29

In article <2261@csadfa.oz> gwg@csadfa.oz (George Gerrity) writes:
>
>   ...binary integers are
>   considerably more compact than decimal codings, and this will be trans-
>   lated into higher I/O throughput and smaller data bases.
>   [ .. other apparently well-reasoned stuff ... ]

When the IEEE FP standard was being formed, some consideration was
given to the idea of decimal encodings.

Normally, one stores decimal as BCD: one digit as 4 bits.  So, 3
digits takes 12 bits, whereas binary gets >1000 patterns in a mere 10
bits. Well, 20% is a penalty, true.

However, about the time of the IEEE standards effort, someone came up
with an encoding which put 1,000 patterns into 10 bits. Further, his
encoding could be transformed <=> BCD with straightforward
combinational hardware. (That is, the logic would have no carry
ripple, or other such nastiness.)

If this idea had been enshrined long enough ago, we would now store
our FP in what you might call "compact BCD". FP units would expand
numbers as they were loaded to registers, and compact them on stores.
Internal operation would be on BCD.

Well, it didn't happen, and it won't, and maybe that's for the best.
But it's an interesting thought.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science