On 03/05/2011 13:22, Olin Lathrop wrote:
> That's a argument for integer versus floating point, not for a BCD
> representation of that integer in particular.  What you really need is ex=
tra
> wide integer support.  32 bits is not enough dynamic range when in units =
of
> cents.

Three common historic solutions:
1) bigger native Integer type. Platform/Hardware limited
2) 64 bit Integer or bigger via software math library on 8, 12, 16, 32=20
etc native integer. c.f. Currency type in VB which is a large fixed=20
point integer. Can in theory work on any platform/word width.
3) BCD arithmetic across as many bytes or words as desired, sort of like=20
Arithmetic on Strings. As per C. But some mainframes had "support" at=20
machine code level.

Another option was that if the most significant bit is 0, then the word =20
is a reduced integer, if it's 1, then the value of that integer is the=20
number of bytes or words storage used for the number. Depending on=20
implementation this allows variable sized integers (a bit like strings=20
in Visual basic which don't just rely on Null terminator like C, but=20
have a size stored at index-1) that can be very big. I forget what the=20
name of the scheme was/is.




I have now two versions of Word to BCD.
One has output array in  43210 display digit order, the other has output=20
in string order  MSD =3D 0, LSD=3D5
A display routine takes second form, adds an optional decimal point and=20
blanks leading zeros apart from digit with dp or last digit and puts in=20
the buffer for the multiplexed seven segment displays.

In JAL 2.4 you can now pass parameters like ( byte in myarray[]) and use=20
count in the procedure to get upper bound rather than a separate byte=20
parameter for each element.





--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.