▼
Posts: 2
Threads: 1
Joined: Jan 1970
Hi HP experts,
does anyone have an experience in RAM effectiveness of program lines (programm effectivity per byte) in different HP calcs ?
E.g. I would be interested in HP42S, HP32Sii, HP48SX/GX, HP49G, HP71B and HP41C/V/X.
- HP32Sii needs 1.5 Bytes minimum per program line. Does this also apply for a HP42s ?
- for example HP41C and HP42S are quite similar concerning their program language and both are using the basic 41C commands:
Does this mean that in average the ratio (bytes/command) is equal for HP41 and HP42 ?
What about the "extra(beyond 41CV)" functions being implemented in the HP42S ? Do they also need only 1 or 2 bytes per command or do they need significantly more (e.g. due to lack of byte table space). Does in average a HP41 XROM command (from plugin ROM module) need the same byte amount like an HP42S "extra" function ?
- What about HP48, HP49, if compared to HP42S and HP41C ?
How many (bytes/command) do they need ?
To conclude: Is RAM = RAM ?
What is a 7 kByte RAM of a HP42S compared to a 2.2 kByte RAM of a HP41C. Is it 3.18x ? Or only 2x (for example)?
Can a 128 kByte RAM of a HP48GX hold 58 times as much "program capacity(efficiency)" as 2.2kByte-HP41CV ?
What about the HP71B and the HP75C/D ?
Regards and thanks,
Matthieu
Edited: 12 Nov 2003, 3:07 p.m.
▼
Posts: 237
Threads: 20
Joined: Mar 2006
It has been awhile sense I have read the 41C manuals, but. As far as I can remember, on the 41C/CV/CX all single function commands need only 1 byte of space and multi function commands take 2 to 3 bytes. Numbered labels need 1 byte, but lettered needs 2 bytes. Numbered goto commands need 1 byte up to 10 and 2 bytes there after and lettered goto commands take 2 bytes. Numbered XEQ commands take 1 byte up to 10 and 2 there after, and lettered XEQ commands take 3 bytes. The same should hold for the 42S sense it is a pocket sized version on the 41CX with extra memory and functions. I know that others here will check me and tell you if I am wrong.
Posts: 785
Threads: 13
Joined: Jan 2005
The newer [and newer] models with huge RAM give/take more memory. I usually count the HP 25 as 1, HP 41 as 1.5 and HP 42/75 as 2, the HP 71/48 as 2.5 and the new models with flash-pointers (HP 49G(+)/48gII) as 3, bytes per keyword. Remember that a 4-level stack has autocopy from T, but may "overflow" to force you to use STOrage, etc..
The languages are different and therefore it's difficult to do a general analysis, but the new models have [usually] so much more RAM to compensate (not 41C - only CV/CX - compared to older models AND definately not 28C, only 28S or 48/49 compared to 41CV/CX), that they "win" every time.
Note that PC connectivity, extra cards, internal FlashRAM, etc features can greatly enhance the memory capacity/limitation.
The speed of the new hp 49g+ is great for usability (and for # binary loops) # VPN #
Posts: 1,041
Threads: 15
Joined: Jan 2005
Well, this doesn't completely answer your question by a long shot, but
48SX commands and 48GX commands "inherited" from the 48SX take 2.5 bytes
each because they're really 5-nibble addresses. Commands new to the 48GX
take 5.5 bytes each because they're really XLIB commands. Other objects
and the various program structures have a variety of sizes.
Anyway, in general, when comparing different operating systems, don't
assume that more memory means that you can have proportionally larger
programs.
Regards, James
Posts: 2
Threads: 1
Joined: Jan 1970
Thank you all for your helpful answers !
BTW, I found out that the HP-48 needs 3 registers (of HP-41 size) to save one real numerical variable. Normally I would expect only 8/7=1.14x but it is 3x as much as a HP-41 needs.
Is this true ?
Best, Matthieu
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
I don't know about the 41, but on the RPL calculators, most real numbers are stored as a 5-nibble prolog, 3-nibble exponent, 12-nibble mantissa, and 1-nibble sign, so that's 21 nibbles, or 84 bits. A few reals, integer values from -9 through +9, can be stored as 5-nibble ROM addresses. Extended reals (used for some internal calculations) have a 5-nibble prolog, 5-nibble exponent, 15-nibble mantissa, and 1-nibble sign, for a total of 26 nibbles, or 104 bits.
The mantissa and exponent are BCD of course. A real's exponent can be -499 to + 499, with negative exponents represented by 1000 - exponent. Similarly, an extended real's exponent can be -49999 to +49999, with negative exponents represented by 100000 - exponent.
The sign nibble is 0 for positive or 9 for negative.
For storage (that is, outside of the Saturn processor), either temporary or long-term, the concept of a "register" doesn't really apply to the 48. Objects of various types and sizes are simply stored one after the other in memory, with every object using a whole number of nibbles.
Keep in mind that the RPL calculators' stack is really a stack of 5-nibble pointers to objects elsewhere in memory.
If I "make another copy" of a real number with DUP, OVER, or PICK for example, it just looks like I've made another copy of the real number; what I've actually done is made another copy of the 5-nibble pointer to the real. All of the stack manipulation commands work with these pointers, never with the objects themselves.
Regards,
James
Edited: 17 Nov 2003, 9:31 p.m.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Thanks, Paul! That explains why doing "mem" on the 48 does not return what I would expect, after a "DUP"
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
Quote: Thanks, Paul! That explains why doing "mem" on the 48 does not
return what I would expect, after a "DUP"
Umm, actually, I'm James, but no matter. Yes, there's a lot of "smoke
and mirrors" behind the RPL magic. Quite a bit more than I've thoroughly
investigated.
Having the stack of pointers only does sometimes conserve memory, and
perhaps more important, it allows the stack manipulation commands to be
fast. And objects in temporary memory are left where they are until a
"garbage collection" is done, at which time objects still referenced by
pointers are packed next to each other to recover the memory used up by
unreferenced objects.
A few other things that sometimes cause unexpected results from MEM are
the last stack, last arguments, and last command lines saves.
One of the subtle things about the RPL calculators' memory usage is that
if you have any pointer to any object within a composite object (a list,
algebraic, or program), then the entire composite is kept in memory. For
example, if you generate a list "on the stack" (really in temporary
memory), and use GET to extract one element from it, then the entire
list is kept in temporary memory for the sake of the pointer to that one
element. Similarly, if an object from a program is left on the stack, then the
entire program is referenced. NEWOB on the element makes it a new object
in temporary memory, with a new pointer to it, so as long as the
original composite or any element of it isn't referenced by any other
pointer, it's eligible for overwriting at the next "garbage collection".
Storing the element in a global or port (but not local) variable, or
including it in another composite or an array, also makes it a new
object and discards the pointer into the original composite.
But if the element of the composite isn't really an object, but a
pointer itself, as in the case of a whole number -9 to +9, then the
pointer is copied to the stack, instead of using a pointer into the
composite.
Note that if the composite was stored in a global variable, the memory
was used anyway. But if I recall a list from a global variable, extract
one element from it, and purge the global variable, then the list is
copied into temporary memory for the sake of the pointer, so I've only
recovered a few bytes as long as I keep the pointer.
Regards,
James
|