Byte sizes (was Re: 2.8M 3.5' floppy

Paul Koning pkoning at equallogic.com
Tue Mar 15 09:06:03 CST 2005


>>>>> "William" == William Donzelli <aw288 at osfn.org> writes:

 >> Umm 6 bits is perfect for BCD, look at IBM's 1620 : 4 bits BCD, 1
 >> bit sign flag/length flag 1 bit parity

 William> Very inefficient. I hope you are not serious.

 William> Back in the 1960s, most data was numeric, due to banking. It
 William> may still be the dominant form (with maybe porn mpgs a close
 William> second). Each field of a database might have 10, 12, perhaps
 William> 16 BCD characters. Why on Earth would you want a sign bit
 William> associated with each one? If the field even needed a sign,
 William> only one would be needed. Parity? That is the job of the
 William> memory controller - having the processor figure out parity
 William> is just a waste of CPU.

That depends on whether you trust the datapath between the memory and
the CPU.  In the 1620, the memory is a separate cabinet, connected by
cables to the CPU cabinet.  A wise designer would run parity on that
interconnect.  That's still true: high end "system on a chip" designs
have ECC memory AND parity (at least) on the buses -- even if they
only run inside the chip.

I don't actually know if there was parity there.  Probably yes, since
there definitely was such a thing as a parity check stop error in the
CPU.

Oh, and of course processors don't ever figure memory parity in
software, only in hardware, so "waste of CPU" can't apply.

As for sign bit per digit, in the 1620 the "sign" bit serves two
purposes -- on the least significant digit it's the sign of the
number, on the most significant digit it's the "this is the last
digit" marker.

Not that the 1620 is all that efficient -- at 12 digits per
instruction, code density was pretty low.

       paul




More information about the cctech mailing list