Re: shortening hp42s program (long...) Message #13 Posted by Vieira, Luiz C. (Brazil) on 18 Aug 2004, 8:45 a.m., in response to message #1 by Tom White
Hi;
this is a little suggestion and I'd like to 'say' a few words about it.
I thought about writing an article mostly related to automatic register stack (RPN calculators) and memory usage (regular numbered registers and variables) while programming and directly using the calculator, but I thought this sort of subject is no longer an issue. Maybe I'm wrong.
When designing calculators in the 70's, designers should deal with expensive RAM circuits, lots of HW resources and control/arithmetic SW development. RPN was, at that time, THE designers solution at the same time it created a new way to develop applications. I still take RPN, and also RPL, as great achievements and powerful tools, but I also like them, so I am not a 'neutral' reference. Today a lot of things have changed: RAM cost is no longer an issue and it is easier ($) to develop the best multi-purpose processor and stuff it in with dedicated SW. Powerful, fast and efficient 'gadgets' are available with a low-cost production. Efficient programming with low memory resources is something like 'state of the art' programming, and I 'feel' as if there is no more space for this sort of development, only when locally required. Some industrial, multi-purpose controllers still offer the HW environment, but the use of high-level languages instead of binary, mnemonic-based development simply enhance productivity, allows non-system programmers to develop system-related applications and... lead to bigger codes. Well, RAM enough for any taste!
Back to calculators: extensive stack manipulation while programming may result in efficient, small and fast programs, but as many contributors discussed in this very forum, RPN/RPL may not be the first choice in many circumstances, but writing programs with these "languages" allow us all to face some teasing tasks like shortening a program.
No further ado: my suggestion is listed below. (consider LineFeed as ALPHA [LF] single character, please)
00 { 127-Byte Prgm }
01•LBL "CAD"
02 SF 21
03 CF 00
04 CF 01
05 CLMENU
06 "DIA"
07 KEY 1 GTO 01
08 "AREA"
09 KEY 2 GTO 02
10 "CIRC"
11 KEY 3 GTO 03
12 MENU
13 STOP
14•LBL 01
15 ENTER
16 STO 00
17 PI
18 ×
19 STO 01
20 ×
21 4
22 ÷
23 STO 02
24 CLA
25 GTO 04
26•LBL 02
27 STO 01
28 4
29 ×
30 PI
31 ÷
32 SQRT
33 STO 00
34 PI
35 ×
36 STO 02
37 SF 00
38 GTO 00
39•LBL 03
40 ENTER
41 STO 02
42 PI
43 ÷
44 STO 00
45 ×
46 4
47 ÷
48 STO 01
49 SF 01
50•LBL 00
51 "DIA="
52 ARCL 00
53 |-"LineFeed"
54•LBL 04
55 FC? 00
56 |-"AREA="
57 FC?C 00
58 ARCL 01
59 FC? 01
60 |-"LineFeedCIRC="
61 FC?C 01
62 ARCL 02
63 AVIEW
64 END
The 'regular' HP42S has 8KBytes RAM, and many 'custom' models have either 32KBytes or 64KBytes, but it is hard to find a way to fill them all with program lines... Also, any Memory Lost would lead to painful 'reload'... Anyway, in any case, memory is not endless, so 'shrinking' programs is not only fun, but RAM saving. Well, as it can be seen, all ''variables' where removed and numbered registers are used. If there is a need to keep variables, all lines from LBL 00 must be rewritten. Yes, I know that numbered registers lack a better reference for their contents, while variables may have their names 'declaring' their contents. I still believe programmers must keep track of their programs as a whole, but when code is too long it becomes more and more complicated to do so. In this case, variables help a lot keeping track... for as long as we have available RAM.
Hope it helps illustrating other alternatives. Please, add comments and suggestions as well.
Cheers.
Luiz (Brazil)
Edited: 18 Aug 2004, 8:49 a.m.
|