DM32 program byte counts

[Joe Horn]

Unlike the HP 32SII, which used exactly 1.5 bytes for every program step (except for literal numbers and equations), the DM32 uses only 1 byte for most program steps, but occasionally uses 3 or 4 bytes for some programmable operations. Here's the complete list (as of v2.02; subject to change in future firmware updates):

BYTES PER DM32 PROGRAM STEP

All programmable functions and commands use 1 byte
except all STO and RCL commands which use 4 bytes each,
and all of the following which use 3 bytes each:

∫FN d var or (i)
CF n
DSE var or (i)
ENG n
FIX n
FN= label or (i)
FS? n
GTO label or (i)
INPUT var or (i)
ISG var or (i)
LBL label
SCI n
SF n
SOLVE var or (i)
VIEW var or (i)
XEQ label or (i)
x<> var or (i)

LITERAL NUMBERS

Unlike in the HP 32SII, literal numbers in DM32 program memory occupy 2 bytes plus 1 byte per digit, decimal point (if keyed in), EEX, sign, fraction mark. If numeric entry is begun by pressing the decimal point key, a leading zero ("0.") is automatically entered. Fraction-notation numbers are stored in program memory as such, e.g. 1.2.3 is stored as 1.2.3, not as its decimal equivalent. The internal format can be seen by pressing SHOW. Example: 2.6.3 is fraction notation for 2+6/3 which equals 4. Keying 2.6.3 into a program is displayed in the program listing as 4, and when run it puts 4 into X, but SHOW reveals that it's stored in program memory as 2.6.3 which occupies 7 bytes.

Some non-obvious consequences of the above rules:

• Don't key 4.E37 into a program; just key 4E37 (one less byte and faster)
• Both .1.3 and 1..3 evaluate as 1/3, but 1..3 uses one less byte and runs faster due to the automatic leading zero rule.
• 1..3 takes two more bytes than 3 1/x but it runs faster.

Corrections and/or additions to the above will be greatly appreciated.

[jonmoore]

It feels somewhat anachronistic to be discussing individual byte counts of a modern ARM SoC, but I suppose that's the beauty of simulating a calculator design first introduced in 1991 (1988 for the original 32S running on the same Sacajawea Saturn hardware).

Excellent investigation Joe.

[rprosperi]

(05-31-2023 08:48 PM)Joe Horn Wrote:  Unlike the HP 32SII, which used exactly 1.5 bytes for every program step (except for literal numbers and equations), the DM32 uses only 1 byte for most program steps, but occasionally uses 3 or 4 bytes for some programmable operations. Here's the complete list (as of v2.02; subject to change in future firmware updates)...

Comforting to know that the true heart of couch hacker never changes....

Thanks Joe!

[Maximilian Hohmann]

Hello!

(05-31-2023 08:48 PM)Joe Horn Wrote:  Unlike the HP 32SII, which used exactly 1.5 bytes for every program step (except for literal numbers and equations), the DM32 uses only 1 byte for most program steps...

Those were the days when 1/2 byte made a difference because only 390 bytes were available in total!

For comparison: This afternoon I went to a computer store and bought a new hard drive for backing up our photos. The previous one (2TB) is full. So I got one twice that size (and at roughly 1/4 the price of a DM32) and, once back home, put it in the enclosure of the old one. To my big surprise, the new disk only showed 2TB instead of 4... Some internet research followed and obviously hard disk controllers have - just like pocket calculators - evolved during the last decade. Back when I bought the last disk, no one thought that 3,5inch disks would ever get bigger than 2 Tera Bytes and therefore the controller chips were limited to that figure. So now I have to go again and get a new enclosure for the larger disk. I chose one that can addess up to 12TB, let's see if that will enough when the next bigger disk is due!

As much as I appreciate the research of Joe Horn for it's historical value I must say that I am soooo glad that memory size does not matter any longer when writing programs. Compared to the file size of digital photos (my current camera genrates raw files of 45 MBytes on average, not to talk about it's capability to take 4k videos...) a few bytes more or less of code luckily make no noticeable difference. It is still necessary to program for speed, especially when large datasets like photos or videos are involved, but no longer for size. What a relief!

Regards
Max

[Joe Horn]

(06-01-2023 05:58 PM)Maximilian Hohmann Wrote:  Hello!

(05-31-2023 08:48 PM)Joe Horn Wrote:  Unlike the HP 32SII, which used exactly 1.5 bytes for every program step (except for literal numbers and equations), the DM32 uses only 1 byte for most program steps...

As much as I appreciate the research of Joe Horn for it's historical value I must say that I am soooo glad that memory size does not matter any longer when writing programs.

The latter is not true, and my posting has more than historical value. You are assuming that the only use of my byte count information is saving memory. You are forgetting the many other values of knowing the internal format of programs and data. "Synthetic Programming", which added powerful and fun functionality to the HP-41, would have been impossible without knowing the exact internal structure of HP-41 programs. Nobody has mentioned it yet, but I predict that synthetic programming will also become A Real Thing on the DM32.

Another real use of byte count information is for optimizing programs' SPEED. I even gave an example of that at the end of my posting above. No, that's not an obsolete idea either, because when a program contains iterative loops, especially nested loops, even a tiny bit of optimization can have a huge impact on total execution time.

Also, it's FUN to delve deeply into these machines, and wrap one's mind around their inner workings. It's one real way for our minds to make direct contact with the minds of the brilliant engineers who created them. We don't ask what's the practical use of the paintings in an art museum; the enjoyment of them fully justifies their existence. I feel exactly the same way about mathematics and computer programming.