The Museum of HP Calculators

HP Forum Archive 13

[ Return to Index | Top of Index ]

RAM = RAM ?
Message #1 Posted by Matthieu T. Vandamme on 12 Nov 2003, 3:05 p.m.

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.

      
Re: RAM = RAM ?
Message #2 Posted by Richard Garner on 12 Nov 2003, 4:30 p.m.,
in response to message #1 by Matthieu T. Vandamme

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.

      
Re: RAM = RAM ?
Message #3 Posted by Veli-Pekka Nousiainen on 13 Nov 2003, 4:11 a.m.,
in response to message #1 by Matthieu T. Vandamme

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 #

      
Re: RAM = RAM ?
Message #4 Posted by James M. Prange on 14 Nov 2003, 5:20 p.m.,
in response to message #1 by Matthieu T. Vandamme

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

      
Re: RAM = RAM ?
Message #5 Posted by Matthieu T. Vandamme on 17 Nov 2003, 6:36 a.m.,
in response to message #1 by Matthieu T. Vandamme

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

            
Re: RAM = RAM ?
Message #6 Posted by James M. Prange on 17 Nov 2003, 9:28 p.m.,
in response to message #5 by Matthieu T. Vandamme

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.

                  
Re: RAM = RAM ? Interesting!
Message #7 Posted by bill platt (les Estats Unis d'Amerique) on 18 Nov 2003, 11:55 a.m.,
in response to message #6 by James M. Prange

Thanks, Paul! That explains why doing "mem" on the 48 does not return what I would expect, after a "DUP"

                        
Re: RAM = RAM ? Interesting!
Message #8 Posted by James M. Prange on 19 Nov 2003, 5:56 a.m.,
in response to message #7 by bill platt (les Estats Unis d'Amerique)

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


[ Return to Index | Top of Index ]

Go back to the main exhibit hall