You're right about the HP15C. Message #5 Posted by Vieira, Luiz C. (Brazil) on 26 June 2003, 12:37 p.m., in response to message #4 by Valentin Albillo
Hello, Valentin;
thank you for your comments. As always, yours are also thoughtful, precise and teasing ;^).
The fact that leads me to conclude the HP42S as having one of the most complex O.S. for an RPN calculator is because it has a different, floating memory organization. Based on some facts, I tell you it uses pointers to existing "objects" instead of available memory to all of them.
As it happens in RPL-structured machines, replicated objects in the HP42S do not use space. Let's take a simple example and start by clearing STACK and LASTX:
[CLST] [+] [×: 0.0000 ] @ this places 0.0000 in all stack
[MEM] [6977 Bytes ]
This is what's shown when the calculator is completely cleared. Now type in any floating point number and check memory.
123.456 [×: 123.456_ ]
[MEM] [6963 Bytes ]
See? Fourteen bytes are automatically allocated to hold the new entered data. Now fill the stack with it and check available memory again:
[ENTER]
[ENTER]
[ENTER] [×: 123.4560 ]
[MEM] [6963 Bytes ]
Should we conclude that the stack occupies 14 bytes? The fact is that no extra bytes are used to hold copies of the same data in all stack registers. Now let's clear all stack and enter different numbers at a time and check available memory for each entered data:
[CLST] [MEM] [6977 Bytes ]
123 [MEM] [6963 Bytes ]
[ENTER] 123 [MEM] [6950 Bytes ]
[ENTER] 123 [MEM] [6936 Bytes ]
[ENTER] 123 [MEM] [6923 Bytes ]
Each entry consumes as many bytes as needed to hold a new number. The O.S. does not check if I'm entering the same numbers, it only requests new bytes to hold it. Each stack entry uses, in fact, 13.5 bytes, and the half byte called my attention to Saturn architecture and RPL organization. Why not thinking the HP42 is an RPL calculator with a stack limited to four register? It would be easy to implement some new short routines in the existing RPL O.S. to emulate the HP41.
You can go any further by testing what happens when complex numbers are generated and how much memory they request to exist. Also when variables are created. I had done that a long time ago, when I bought my first HP42S (R.I.P., poor girl...), but I cannot find my notes. It's revealing. I also had a complete XROM map for it... all lost.
You see, the HP15C handles a small amount of memory and it does wonders with it. But it is somewhat easier when you know exactly where are all stack registers and their precise location, even if they grow in an exact number of five registers. Also, when computing SOLVE or INTEGRATE, I wonder if the 23 registers needed to accomplish the task are mapped in memory or not. I'm not sure if imaginary stack is created in the same portion of memory everytime it is activated, mostly because SOLVE and INTEGRATE do not use imaginary stack contents unless you explicitly use Re<>Im, and this technique is shown in the HP15C's Adv. Fcn. Hanbook. And one very convenient fact is that if complex mode is active, imaginary stack contents are cleared everytime a function is evaluated by SOLVE or INTEGRATE because both can only sample real data and the stack is filled with this sampled data before to evaluate function to be integrated or solved for. Well, in fact, if you set flag 8 or execute [f][I] or [f][Re<>Im] while computing SOLVE or INTEGRATE is different of activating complex mode before or after computing any of them. Where in memory will imaginary stack registers be created if they are created while running SOLVE or INTEGRATE procedure? In this case, is it possible to "pause" SOLVE or INTEGRATE computing and use complex numbers by direct keyboard operations? I'd like knowing it for sure and I did not test it.
There's more to talk about HP42S memory management and RPL memory "tricks", but I'll do that later, if needed.
Thanks, Valentin; I was not sure about when I'd post something about this.
Luiz C. Vieira - Brazil
Edited: 26 June 2003, 4:05 p.m.
|