Assorted WP-34S beginner questions

[Paul Dale]

(07-21-2014 10:08 AM)sa-penguin Wrote:  A search of the trunk for "COS" shows it in commands.c xeq.h complex.c but I'm blessed if I can find where cosines are actually evaluated.

All user functions are listed in commands.c. Looking at the COS entry there:

Code:

    FUNC(OP_COS,    &decNumberCos,        &cmplxCos,    NOFN,        "COS",        CNULL)

This means that the opcode is based on OP_COS, the real version of the function is decNumberCos, the complex version is cmplxCos and that there is no integer version (although the automatic defaulting will take place I think and use the real version here in a very uninteresting manner). The function name is COS and there is no alias for this function for the assembler.

From this, it is straightforward enough to search for decNumberCos which lives in decn.c


This is the same process I use to find many functions. I don't remember where they all live, although I can often guess it is faster to look in commands.c first.


- Pauli

[sa-penguin]

(07-21-2014 11:27 AM)Paul Dale Wrote:  All user functions are listed in commands.c. Looking at the COS entry there:

Code:

    FUNC(SOME_FUNCTION,     &realVersion,    &complexVersion,    &integerVersion,    "FUNCTION",    ASM_ALIAS)

So - functions are defined with:
1. What the opcode is based on,
2. Real version name,
3. Complex version name,
4. Integer version, then
5. Assembler alias

Thanks, knowing what the fields refer to is a great help.
I've tracked the actual code to the routine sincosTaylor(). Now my education begins.

[Paul Dale]

(07-21-2014 12:21 PM)sa-penguin Wrote:  Thanks, knowing what the fields refer to is a great help.

The xeq.h file contains the structure definitions for all the various command tables. The rest should be obvious enough. However, you'll have quite some difficulty tracking the build process used on these. We pulled some serious optimisation games to halve the size of all the pointers.

Quote:I've tracked the actual code to the routine sincosTaylor(). Now my education begins.

This is a straightforward implementation of the series expansion. Nothing special or exciting really


- Pauli

[sa-penguin]

(07-21-2014 09:45 PM)Paul Dale Wrote:  

(07-21-2014 12:21 PM)sa-penguin Wrote:  I've tracked the actual code to the routine sincosTaylor(). Now my education begins.

This is a straightforward implementation of the series expansion. Nothing special or exciting really

Actually, I got a farm & fuzzy feeling from looking at the code & working out what it did.

I'm going to try remembering that feeling because, following the code down, I reached the decAddop() function for adding 2 numbers.
That's a lot of code, covering assorted precisions, number of digits, packed BCD and more.

Maybe I need an "IEEE-754 for dummies" to explain it all.

[Paul Dale]

I don't bother tracking stuff down into the bowels of the decNumber library. The low level arithmetic functions are pretty convoluted -- they have to work with arbitrary precision, they have to correctly round and they need to be reasonably efficient.


- Pauli

[sa-penguin]

(07-27-2014 11:47 AM)Paul Dale Wrote:  I don't bother tracking stuff down into the bowels of the decNumber library. The low level arithmetic functions are pretty convoluted -- they have to work with arbitrary precision, they have to correctly round and they need to be reasonably efficient.

I, on the other hand, am now starting to understand more - and may even try modifying some of the code.

By deliberately limiting the precision to 4096 digits, and merging with 4 status bits, for example. Result fits into a 16-bit integer, instead of being spread over five bytes, and keeps al variables word-aligned.

There's also DECPUN (Decimal numbers per unit), which defaults to 3. Changing this should reduce the number of bytes needed to hold variables - at the expense of computing speed. According to DecNumber Tuning Parameters, anyway.

Setting DECPUN to 9 (3 groups of 3 packed BCD numbers = 30 bits) stored in a 32 bit double-word gives 45 digits in 20 bytes, vs the current 39 digits in 26 bytes.

Is the saved memory worth the extra effort? A good question.

[Paul Dale]

(07-30-2014 05:44 AM)sa-penguin Wrote:  By deliberately limiting the precision to 4096 digits, and merging with 4 status bits, for example. Result fits into a 16-bit integer, instead of being spread over five bytes, and keeps al variables word-aligned.

I don't think the firmware ever uses this many digits -- the big mod function is the worst I believe which uses 820 digits. So this change should be beneficial. Be aware that bit fields are kind of expensive in THUMB mode (which we use), hence all the myriad access functions to centralise their use.

This change would reduce stack usage during computations. We've overflowed the stack a few times but not currently as far as I'm aware -- matrix and statistical distributions are the prime culprits here and I changed the internal precision on the former and moved the latter to XROM to avoid the issue. It would also save a number of bytes in the constants but not a huge number -- still every byte is precious.

Quote:There's also DECPUN (Decimal numbers per unit), which defaults to 3. Changing this should reduce the number of bytes needed to hold variables - at the expense of computing speed. According to DecNumber Tuning Parameters, anyway.

The impact of changing this is massive and detrimental. This one we did experiment with a little. The calculator is converting between DPD and decNumber formats all the time and making this a very expensive operation, which is what changing this does, hurts a lot. As mentioned above, the unpacked decNumber format isn't the problem generally.


- Pauli