AVR Freaks

I'm not talking about floats or fixed point. Accuracy is much more important than speed for me.

http://en.wikipedia.org/wiki/Dec... is used to accurately represent base-10 numbers. Calculators, databases, etc. use it. Java's BigDecimal class uses decimal floating point.

Intel has a decimal floating point library called BID, but it seems very x86-centric and difficult to port.

I worked on porting DFP tonight and so far I've been successful. I'm doing a straight port from Java to C on my Mac first just to make sure the algorithms work correctly, but I run it through avr-gcc from time to time to get a feel for the code size.

So far I've ported the four arithmetic functions, comparisons, negation, and rounding. The code works very well but it's extremely inefficient and huge at this point.

Based on what I've seen, the functions will probably be far too complex and slow for real-time applications, but I'm going to use it to make a 12-digit scientific calculator, probably with a 'mega328P.

I agree. The library I'm looking at was written in *shudder* Java. Very inefficient Java.

I guess the only upside is that the code is easy to understand and porting to C isn't too hard. However, I'm going to rewrite significant portions of it in assembler afterward.

Jacques' page about the HP35 is extremely interesting. I'm sure I'll use some of the techniques described there to replace the more naive parts of the Java implementation.

I am using unpacked BCD. Constants (from log and arctangent tables) are stored packed in ROM and are unpacked when needed. The main slowdown is probably due to the large amounts of copying, shifting, and iteration required.

The math routines are written in assembly but can be called from C. To simplify the assembly code, the functions don't operate on arbitrary variables. Instead, operands are first loaded into static intermediate "registers." For example, to divide 123.4 by -5.678 in C, you'd perform the following:

Having the operands in known locations in memory greatly reduces the number of indirect load/stores in the math routines. Of course, it would be possible to abstract the details of the intermediate registers away and write functions that take dfp_unpacked structs as arguments. However, in its current state it fits the "scientific calculator" paradigm very well.

Here are a couple assembly snippets. The first is the private "add" subroutine, used to add the mantissas of positive numbers with their decimal points aligned:

The actual plus routine is more complicated, since it has to deal with unaligned and negative operands. However, this snippet is called often in many other functions that perform repeated addition.

Here's the common logarithm function, which performs ln(x)/ln(10). First, the natural log of the B register is taken and returned in register A. A is copied to B (the dividend register) and ln(10) is loaded from program space into C (the divisor register). The division routine then stores the quotient of B/C in A.

jayjay1974: Square root is computed with a method from a 1962 paper called "Pseudo Division and Pseudo Multiplication Processes." It describes how to calculate all the elementary functions with only adds, shifts, and lookups. These are the same algorithms that were used in the HP-35.

It might not be tiny or blazing fast; it's mainly an exercise for me to practice AVR assembly and learn the techniques used by the first calculators. However, it actually seems to be working, which is a nice surprise :)

Hello again,

The routines are pretty much complete. The library includes the following functions, that operate on 12-digit numbers with two guard digits:
- zero, copy, negate, absolute value, integer part, fractional part, sign
- add, subtract, multiply, divide, square, reciprocal
- square root, nth root, power, log, log base 10, exponential
- sin, cos, tan, asin, acos, atan
- sinh, cosh, tanh, asinh, acosh, atanh

There is also a status byte that indicates if the last operation caused an error (divide by zero, out of domain, etc.)

The code weighs in at just over 3K. (This includes a 232-byte constant table in ROM; without the table, it's under 3K.)

90 bytes of RAM are used for five 18-byte, 16-digit unpacked BCD registers; A, B, C, M, and T. A is the accumulator/result register. B and C are operand registers. M is used during the CORDIC operations. T is a temporary register used by a couple of the higher-level math functions.

I'll probably release the code in the future, after I build some hardware and get this running on an actual chip.