(03-12-2014 02:25 AM)Sikuq Wrote:  What surprised me was the persistence of the locals even after I exited the program but did not yet detach the pointer. I was wondering if the internal local assignment perhaps was stored in a faster but volatile memory bank (i.e. stack) than the global registers. Unfortunately I don't know if the 34s hardware has such internal sophistications. That's why I try to on-stack my interim data as I assume it is a lot faster to do stack rolls than say STO xx and then RCL xx.

Quote:While here, did you touch upon the internal housekeeping of the 34s in respect to (de)fragmentation of files? Do the files individually have to be completely contiguous?

(03-12-2014 02:39 PM)walter b Wrote:  Hey, hey, Sir, I was just recommending App. B since it's clearly stated there where the local registers live. But if you feel you've not done your homework there may be a reason, doesn't it?

BTW, may I ask you to use the button <Quote> instead of <New reply> - it makes it so much easier to detect to which post you are responding. TIA

d:-)

(03-12-2014 02:47 PM)Sikuq Wrote:  One thing I can't figure out is how to order the posts with the newest on top. As is I have to scroll down several pages to get to the latest stuff. Any navigational suggestions?

(03-12-2014 04:19 PM)Sikuq Wrote:  I also wish the QUOTE button had been labeled ANSW or REPL. Now, I ain't bitching none, but I do wonder just why the designers didn't simply order the entries the way the three of us (and thus most likely a lot more) would have preferred it - at least as an option.

(03-12-2014 04:26 PM)walter b Wrote:  

(03-12-2014 04:19 PM)Sikuq Wrote:  I also wish the QUOTE button had been labeled ANSW or REPL. Now, I ain't bitching none, but I do wonder just why the designers didn't simply order the entries the way the three of us (and thus most likely a lot more) would have preferred it - at least as an option.

Then everybody would have found the right button, this way you didn't find it again ...

Seriously, this discussion now belongs to the test forum IMHO.

d:-)

(03-12-2014 10:14 PM)Marcus von Cube Wrote:  Let's talk about facts again.

The Atmel processor is a very limited device. It's fast (at high clock speeds) but it's lacking memory to an extend which made Pauli and me geniuses in saving flash and RAM space. This has several impacts:

We cannot use the processor to its full extent because flash is so limited that we had to use the so called thumb mode which features a reduced instruction set with a smaller memory footprint at the cost of slower execution (limited instruction and processor register set). The code is optimized for size, not for speed. There are some crude manual optimizations just to squeeze out as much user flash for library functions as possible.

The limited RAM forces us to pack everything as tight as possible which slows down access (e. g. bit fields for flags).

OTH, limited means simple: no dynamic memory (and thus no memory leaks), all sizes are known, memory is moved and not linked via pointers, ...

To answer your questions about different memory types in the device. There are three:

1. Non volatile RAM, 2KB. This is user memory, holding all the registers, flags, and the program steps which can be edited directly on the device.

2. Volatile RAM, 4 KB. This can only be used temporarily for internal operations.The contents is lost whenever the processor goes idle, that is when user input is being awaited. We use it as the internal processor stack, and for most internal calculations.

3. Flash memory, 128 KB. Most of it contains the firmware. Some KB are available to the user to backup of the non volatile RAM (2KB) and for keystroke programs known as the library. These cannot be directly edited but copied to and from non volatile RAM or compiled externally and sent to the calculator as part of the firmware (calc_full.bin). This memory area is slightly slower than the other two but it doesn't really matter for the keystroke programs stored in flash. The impact on firmware execution speed is of more importance.

To add some info about what Pauli wrote about access to local and global registers:

Global registers move around in memory, depending on the number of registers allocated (REGS command), and whether double precision mode is in effect or not. Thus, finding a specific register needs a few instructions (shifts and adds). Local registers a similar in nature: There size is variable (double precision or not) and their location is dynamic: they live on the subroutine return stack, the same that manages XEQ and RTN. The effort to find such a register in memory is comparable to that of finding a global register, just a few adds and shifts. The distinction between local and global is done through the internal index: 0 to 111 is global, 112 and higher is local and requires a different access path. To be precise, the range 100 to 111 for the lettered registers requires its own scheme but it deviates only minimally from that for 0 to 99. The effects on execution time should be negligible.

When local registers are allocated, RTN is a bit more involved because it not only needs to pull the return address off the subroutine return stack but also has to skip the local register frame and needs to setup some internal pointers to reactivate the local registers of the caller. Repeating LocR commands on the same stack frame (adjusting the available number of registers) has to move some memory around which may affect performance. The latter should be a rare case anyway.

Just enjoy the features. That's why we have implemented them.

(03-12-2014 11:17 PM)Sikuq Wrote:  I hugely appreciate this outstanding explanation. It answers most of my questions. I am impressed that you took the time to write this lengthy insight on the forum. I hope many other 34S users can read it as well.

(03-12-2014 11:17 PM)Sikuq Wrote:  PS: All those mathematical functions in the 34S libraries, just how do they work?

Quote:The flash library is an assortment of keystroke programs. Their commented source code can be found in the library folder on SourceForge.

All the built-in stuff can be divided in two groups:

1. Native code ...

Quote:(Please notice that there is no need to quote a large posting completely.)

(03-13-2014 09:20 PM)Sikuq Wrote:  However I always wondered just how the 34S actually calculates say a square root or the Gamma function. Does it use a power series, other basic functions, or say Fourier? And did you get those functions from somewhere else and just compiled them in there?