Next: Where is balance? -- Re: Academic priorities
From: John Savard on 30 Mar 2005 02:49
jon(a)beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0503290421.76e8451a(a)posting.google.com>...

> Er? Even the smallest current FPGAs support tens of thousands of gates
> with the larger devices supporting hundreds of thousands.

There. You see? You can't get an FPGA with as many gates as a Pentium
IV microprocessor.

John Savard
From: Chris on 30 Mar 2005 04:14
Mark Thorson wrote:
>
> I recently acquired an IBM 650 manual, and I was
> interested to learn that it used a biquinary
> representation for integers. This is a decimal
> format, in which five bits represent the values
> 0-4 or 5-9 and two binary bits select between
> the upper and lower range of values. (In other
> biquinary formats, a single binary bit may be
> used to select between upper and lower.)
>

<snipped>

Perhaps you mean 2 bits to decode any state ?. In the days of discreet
transistor designs, it was a way of minimising parts count, and timing
skew (counter is synchronous), thus maximising count frequency. Using a
Johnson counter configuration, the number of count states is equal to
(stages * 2) and only 2 bits are required to decode any state. eg: a 5
stage counter counts to 10. Quite an old idea in fact and dates back to
tube days, when active device count really mattered.

ISTR, an early HP counter from the 60's used a biquinary counter as a
high frequency prescaler, but memory fades...

Chris
From: Terje Mathisen on 30 Mar 2005 04:36
John Savard wrote:

> Mark Thorson <nospam(a)sonic.net> wrote in message news:<4248AB7A.FF5B46B5(a)sonic.net>...
>
>
>>FEWER GATES -- biquinary allowed reducing the
>>amount of logic by using ring counters for adding
>>by repeated increments.
>
>
> That's precisely why we can't use biquinary today. Adding would become
> much slower, as it would be done by counting to five.
>
> Also, it would waste bits in memory.

I agree.
>
> If *decimal* got revived, it would be by means of something like
> Chen-Ho encoding, or the recent elaboration of it known as Densely
> Packed Decimal.

PDP is interesting. From reading Mike Cowlishaw's description of some of
its key benefits I figured out how to do it, only it turned out that I
had generated a nearly but not totally equivalent packing method.

Mike's original version can be implemented with less fixed logic (and/or
lookup tables), but for a pure sw implementation of decimal, it is
possible that it would be faster to skip it and simply work in base-1000
all the time, and then suffer some additional cost for unpacking/packing
each time a decimal shift of one or two digits was needed.

Terje
--
- <Terje.Mathisen(a)hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
From: John Savard on 30 Mar 2005 10:45
Terje Mathisen <terje.mathisen(a)hda.hydro.com> wrote in message news:<d2drvk$bvr$1(a)osl016lin.hda.hydro.com>...

> PDP is interesting. From reading Mike Cowlishaw's description of some of
> its key benefits I figured out how to do it, only it turned out that I
> had generated a nearly but not totally equivalent packing method.

I did the same thing, as a representation with such properties is not
unique, when I deigned to explain DPD on my web page, at

http://home.ecn.ab.ca/~jsavard/crypto/mi060301.htm

which I did because I revisited the main topic on this page, a nested
Chen-Ho type encoding which encodes, very efficiently, 47 bits in 10
letters of the alphabet. (As you may note, these are pages about
cryptography; the idea is to combine new-fangled binary ciphers with
old pencil-and-paper ciphers while adding very little redundancy.)

I revisited it because I received an E-mail pointing out an error I
made on the page.

I then *modified* DPD so that in addition to trimming off leading 0
bits corresponding to leading 0 digits, one could trim off leading 1
bits corresponding to leading 9 digits. I did _that_ because I was
working on an example computer architecture (once again off my pages
for now due to space limitations, but look for it to be back soon,
perhaps in as little as two weeks - the original, simpler version is
still up on another site) which used ten's complement representation
for decimal numbers.

John Savard
From: Delbert Cecchi on 30 Mar 2005 23:18

"Chris" <invalid(a)devnull.com> wrote in message
news:424A6DCF.B2FCD394(a)devnull.com...
> Mark Thorson wrote:
> >
> > I recently acquired an IBM 650 manual, and I was
> > interested to learn that it used a biquinary
> > representation for integers. This is a decimal
> > format, in which five bits represent the values
> > 0-4 or 5-9 and two binary bits select between
> > the upper and lower range of values. (In other
> > biquinary formats, a single binary bit may be
> > used to select between upper and lower.)
> >
>
> <snipped>
>
> Perhaps you mean 2 bits to decode any state ?. In the days of discreet
> transistor designs, it was a way of minimising parts count, and timing
> skew (counter is synchronous), thus maximising count frequency. Using
a
> Johnson counter configuration, the number of count states is equal to
> (stages * 2) and only 2 bits are required to decode any state. eg: a 5
> stage counter counts to 10. Quite an old idea in fact and dates back
to
> tube days, when active device count really mattered.
>
> ISTR, an early HP counter from the 60's used a biquinary counter as a
> high frequency prescaler, but memory fades...
>
> Chris

I would bet that the 650 had vacuum tubes, not transistors. Sorry I'm
too lazy to go to the archives at www.ibm.com and check.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Next: Where is balance? -- Re: Academic priorities