Assorted WP34S beginner questions

07212014, 11:27 AM
Post: #21




RE: Assorted WP34S beginner questions
(07212014 10:08 AM)sapenguin 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 

07212014, 12:21 PM
Post: #22




RE: Assorted WP34S beginner questions
(07212014 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. 

07212014, 09:45 PM
Post: #23




RE: Assorted WP34S beginner questions
(07212014 12:21 PM)sapenguin 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 

07272014, 11:00 AM
Post: #24




RE: Assorted WP34S beginner questions
(07212014 09:45 PM)Paul Dale Wrote:Actually, I got a farm & fuzzy feeling from looking at the code & working out what it did.(07212014 12:21 PM)sapenguin 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 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 "IEEE754 for dummies" to explain it all. 

07272014, 11:47 AM
Post: #25




RE: Assorted WP34S beginner questions
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 

07302014, 05:44 AM
Post: #26




RE: Assorted WP34S beginner questions
(07272014 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 16bit integer, instead of being spread over five bytes, and keeps al variables wordaligned. 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 doubleword 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. 

07302014, 06:39 AM
Post: #27




RE: Assorted WP34S beginner questions
(07302014 05:44 AM)sapenguin Wrote: By deliberately limiting the precision to 4096 digits, and merging with 4 status bits, for example. Result fits into a 16bit integer, instead of being spread over five bytes, and keeps al variables wordaligned. 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 

« Next Oldest  Next Newest »

User(s) browsing this thread: 2 Guest(s)