|Re: I have a question about "Word Size" and Memory|
Message #4 Posted by Vieira, Luiz C. (Brazil) on 28 July 2004, 2:11 a.m.,
in response to message #1 by Bill Platt
Hi Bill, guys;
I am simply not well versed in the hardware aspects of computing.
About ten to fifteen years ago, I'd say conversely; nowadays, I am not so sure I can say that... But I think I can add a few words over John and James' elucidating posts.
(...) 1. 33s having a 255 character limit for an equation; 2. 12c platinum having problems with goto if the line number exceeds 254? (255? 256?)
Since 2^8 = 256, does this mean that such limitations are hardware dependent?
I'd add that more than 256 possible instructions exist in the HP12Cp programmable repertoire, so some two-byte codes were added to the existing set. John's words corroborate this reasoning of mine, and I'd go a bit further: the information shown when [g][MEM] is pressed is how many program lines are used by programs, and we do not know if there are two-byte instructions in any of them. Based on this, if a 399-step program has all steps filled with these 'hypothetical' two-byte instructions, it would need 798 bytes instead of 399. Something to think of...
3. Switching "Modes" in casios, or the 30s, causing all memory to be lost.
I found myself confused with a particular memory count in the HP9S that I'd like to share with you, contributors, and know your thoughts about this. When in STAT mode (the HP9S allows one-variable statistics only), the HP9S can hold up to 80 different entries with up to 255 occurrences for each, provided that final count does not exceed 20400 entries. Well, what amuses me is the fact that the individual entries are editable! If you enter 80 different values and want to change each of them, you can do that. O.K., there is a limit of 80 full-precision values, but I'd ask how many times did any of you analyze a sample with so many items. Entering each data is tiresome, I know, but having each of them to edit later is amazing. All RPL-based calculators (plus some top-line financial) use lists contents as statistical data. The HP42S has a 'pseudo' list handling, but it actually allows a [n×1] or [n×2] matrix to be the argument for [SIGMA+]. This way, editing the matrix and entering it again is faster than editing the summation data with [SIGMA-] and [SIGMA+]. Back to the HP9S: it has memory "space" that is enough to hold up to 80 statistics entries, but it has only five "memories" when it is in normal mode. Yeap: the extreme case is when the HP9S is set to Complex mode (weird, somehow weird) and you already have an intermediate complex number stored in [a] and [b] and want to add/subtract/divide/multiply to a new complex: it needs to hold real and imaginary parts of both complex numbers until [ENTER] is pressed, and it needs four registers. The fifth one is [M], that can hold an extra value. Well: what are the other 75 registers that MUST exist to hold statistical data holding when the calculator is not in statistical mode? Opposed to the HP30S, the HP9S has no historic stack to hold previous operations. Any clues? I guess I have one. I got used to "see" all "user memory" in RPN calculators since I started using an HP41. Untill I begun dealing with digital electronics and was only a calculator user, I was not 'completely' aware of the fact that somehow the algebraic calculators needed extra memory to hold a stack of numbers, operators and pending parenthesis. This extra memory cannot be used unless you disable the algebraic pending operations and free this memory. Well, when the HP9S is in STAT mode, parenthesis do not work the same way as they do in normal mode...
How do I educate my self about this stuff efficiently?
I think each new non-RPN calculator, from HP or any other brand, has its own operating characteristics and in some cases, they must be mastered one at a time. Some wise, thoughtful and very respectable contributors in here sometimes point RPN deficiencies that actually exist, but I particularly take RPN as the most "transparent" interface when user memory is the issue. Neither RPL nor algebraic interfaces allow this "memory virtual viewing". RPN calculators allow the user to handle up to four numbers in a four-register stack structure plus a fifth "error-recovering" register; the remaining memory is divided into registers to hold numbers or, in some cases, alternative data (ALPHA strings, matrix descriptors, program steps, etc.). Its operation is unambiguous and the stack contents can be predicted for a given keystroke sequence: one does not need to "press the keys" to "see what happens". On the other hand, after keying in some numbers, pressing operation keys and opening a few parenthesis, I may have no idea of how much memory an algebraic calculator has already spent to hold the pending operations, but I know that I cannot use this same memory for other purposes, even if I have no need for pending operations. I guess this is the main reason for the "memory loss" you mentioned before. STAT data and pending operations are not compatible, so this "shared memory" must be cleared when modes are changed.
And about "words" "nibbles" etc?
The HP32S was the first calculator I saw that counted X.5 bytes for programs. This .5-byte is actually a group of four bits, named "nibbles". Each time half of a byte is used as stand alone or composing a group of bits associated to some sort of data, naming these four bits a "nibble" is faster and easier. At least I guess so. The term "word" related to digital information and memory has some different "interpretations" and applications. I have already seen "word", "double word" and the like referring to 16-bit and 32-bit data respectively. I also saw "word" as a reference to the standard data a system (or processor or memory) can handle (or process or store) at the same time, being the "system data unit". This last definition does not state how many bits a word has, it depends on the system (processor, memory) structure. I explain this everytime I am asked about and everytime I spontaneously mention this fact. I still don't know what is correct, if any.
I guess I wrote too much.
Edited: 28 July 2004, 2:37 a.m.