Daniel Jarboe wrote:
> memory fades...). Over the years I don't remember running across
> the 0-99
> idea, however. It is certainly more memory efficient than storing
> one BCD
> per byte, and maybe a little more computational efficient than
> storing two
> BCD digits per byte.
>
> BCD is almost always implemented with two base-ten digits per byte,
> though, so talking about this being more efficient than once BCD per
> byte is a little silly.
Right. Two "Packed" BCD digits per byte. One "Unpacked" BCD digit per byte.
Unless you've done some IBM 370 assembler in your past, this is probably
foreign to you.
Read through this link real quick:
http://en.wikipedia.org/wiki/Intel_BCD_opcodes
As for a binary integer representation of a number between 0 and 99:
8 bits can hold an integer from 0 to 255.
7 bits can hold an integer from 0 to 127.
As 99 is less than 127, you can save a whole bit by not introducing an
articial breakup into a nibble per decimal digit. The high bit remains
unused.
But this isn't what either of you are talking about. We're really not
talking about BCD at all.
> A quick google search for a name, turned up this sight which refers to
> it only as a "base 100 derivation" of BCD.
> http://www2.hursley.ibm.com/decimal/decifaq5.html#otherenc
> <http://www2.hursley.ibm.com/decimal/decifaq5.html#otherenc> It also
> indicates they are more complicated to work with.
With a CPU with opcodes that support BCD math, the processor is aware of
the nibble-wise breakup of the digits and uses adders on each nibble.
They are more complicated to work with in that you need to pack/unpack
them and convert them to/from normal integer representations before
manipulating them with "standard C libraries" that usually know nothing
of BCD numerical representations (sprintf has "%d", there isn't a BCD
argument equivalent).
> I'm not sure why. BCD addition would be binary addition + 6 for each
> nibble > decimal 9.
BCD doesn't use values > decimal 9.
If you add up the digits of the least significant nibbles and the result
is > 10, that needs to be carried to the most significant nibble
addition (a carry) and the modulus needs to stored in the least
significant nibble.
What happens when you add two digits together (like 9+9) and they exceed
the capacity of the nibble of storage for the result (4 bits = 0 to 15)?
Carry logic is quite important.
This isn't hard when you have 4bit adders and the ability to chain the
logic on your CPU core (or microcode it, or however your CPU design
handles microops/VLIW).
> With base 100 it's the same deal, except you add 156 to every byte >
> 99. And converting to decimal form would probably be easier because
> you are working with byte rather than nibble unites. Maybe the author
> was speaking from a hardware/ALU perspective.
I am interested to know wether Paul is concerned with storing values >
100 in this "storage format". If so, you would break up a number into
significant bytes.
This is where "endianness" comes in. Most significant byte, most
significant bit, etc etc. If you limit each byte of storage to an
integer value respresenting 0 to 99, you would break up the number into
digit pairs and store each digit pair in a byte.
Any math that extends over these bytes would need to be aware of the
need to carry results > 100 to the next more significant byte addition.
In this case, no, I don't know what this kind of storage would be
called. Perhaps "decibytes", you could make up your own name for it.
It's just integer values limited to 0-99 stored as bytes.
I also can't think of any CPU opcodes that can handle this format
natively. Meaning, your math wouldn't be nearly as fast as using
something that your CPU _can_ understand natively (be it short/long
integers or BCD).
Can we please just drop this BCD talk please? I don't want to confuse
anyone.
- Ian
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:16:24 EDT