HP 49G, 49g+ & 50g: Built-in Zints - Printable Version +- HP Forums (https://www.hpmuseum.org/forum) +-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html) +--- Forum: General Forum (/forum-4.html) +--- Thread: HP 49G, 49g+ & 50g: Built-in Zints (/thread-8952.html) Pages: 1 2 |
HP 49G, 49g+ & 50g: Built-in Zints - Gerald H - 09-01-2017 09:18 AM In my Sys RPL programmes I use names such as Z0_ to represent the built-in form of ZINT 0 thus reducing the size of programmes & hopefully making them faster. Below is a list of such names & corresponding addresses from: HP49G Entry Reference Complete listing sorted by functionality Edition 2.11, 30 May 2005 I have checked that the addresses on the left are unchanged in OS 2.15. Code: 2733F (Z-9) -9 RE: HP 49G, 49g+ & 50g: Built-in Zints - Joe Horn - 09-01-2017 12:06 PM Those of us who use HP's unmodified extable library can still use your source code if we add equates like these at the top of source code: EQU Z0_ 273AB ... right? (Or must the address be nibble-reversed? I can never remember.) RE: HP 49G, 49g+ & 50g: Built-in Zints - Gerald H - 09-01-2017 12:24 PM Yes, that works as you have it, not reversed. RE: HP 49G, 49g+ & 50g: Built-in Zints - rprosperi - 09-01-2017 02:11 PM Gerald - thanks for explaining this and the table. Where is the entry listing you mentioned available? I looked on hpcalc.org briefly, but not sure of the proper name or description so maybe I missed it. I can find Z0 in Carsten Dominik's Entry Reference (same as you mentioned?) but it does not contain Z0_ Also, what was the purpose of the extended extable you mentioned? Did it simply add other undocumented but stable entry points like this series of ZINTs or what is for use with some other (non built-in) tools? RE: HP 49G, 49g+ & 50g: Built-in Zints - Gerald H - 09-01-2017 03:42 PM I use emacs 2.11 & I believe the extable came with it. I did not initiate the use of Z0_ for PTR 273AB, I presume it was the emacs author. Edit: The document is available at https://staff.science.uva.nl/c.dominik/hpcalc/entries/hp49g/entries.pdf RE: HP 49G, 49g+ & 50g: Built-in Zints - rprosperi - 09-01-2017 05:21 PM (09-01-2017 03:42 PM)Gerald H Wrote: I use emacs 2.11 & I believe the extable came with it. Thanks. That same document is also on hpcalc.org, but this document does not define "Z0_", only "Z0", so unless the trailing underscore has some specific meaning for emacs, I'd assume the extable included with emacs must use slightly different symbols, perhaps to denote unsupported entries. Anyhow, the address of the shorter constant is all that matters, just curious about the odd naming. Thanks again for sharing this. RE: HP 49G, 49g+ & 50g: Built-in Zints - DavidM - 09-01-2017 05:41 PM (09-01-2017 05:21 PM)rprosperi Wrote: Thanks. That same document is also on hpcalc.org, but this document does not define "Z0_", only "Z0", so unless the trailing underscore has some specific meaning for emacs, I'd assume the extable included with emacs must use slightly different symbols, perhaps to denote unsupported entries. Anyhow, the address of the shorter constant is all that matters, just curious about the odd naming. The trailing underscore usually denotes that the entry is "unsupported but stable", and has been used not just by emacs but also in other listings as well, including the default entry point files included with Debug4x. Given that we're unlikely to ever see another firmware update for these systems, the distinction between "stable" and "permanent" is less clear. That doesn't mean you can assume that everyone has the 2.15 firmware, of course. RE: HP 49G, 49g+ & 50g: Built-in Zints - Christoph Giesselink - 09-01-2017 07:06 PM (09-01-2017 09:18 AM)Gerald H Wrote: In my Sys RPL programmes I use names such as Using #273AB as pointer for ZINT 0 save 6 nibbles of code but defintely makes execution slower! In the case of the most other constants you save 7 nibbles, 5 nibbles length field, the number of digits (1) and the sign nibble. Execution is slower because executing an RPL pointer is nothing else than leaving the current RPL stream and calling a subroutine. Code: Using undocumented RPL entry points in general has always the risk that these entry points are moving and so your program may not work on every published OS version. Sometimes you have no chance to avoid using undocumented entries, because there's no equal functionality with supported entries, but in the actual case you save 3 or 3.5 bytes! when using an undocumented entry. Is it worth? Think about. I know that Wolfgang Rautenberg massively used undocumented entries in his HP49 tools to save some nibbles, but in the early times with new ROM's from time to time, some of his programs quit working because some of the entries moved. RE: HP 49G, 49g+ & 50g: Built-in Zints - Gerald H - 09-01-2017 07:59 PM Concerning timings you are wrong. On a 50g timing this programme Code: « 1 10000 with Code: :: as Z3 took 25.9489s with Code: :: as Z3 took 26.9957s RE: HP 49G, 49g+ & 50g: Built-in Zints - Gerald H - 09-01-2017 08:23 PM & on a 49G, OS 1.19-6 Z3_ time 79.1s ZINT 3 time 81.1s RE: HP 49G, 49g+ & 50g: Built-in Zints - Joe Horn - 09-01-2017 10:20 PM I can confirm Gerald's surprising timings. Consider this program: << 1. 10000. START 3 DROP NEXT >> If it is compiled as usual, using an ordinary short-form 3, hex 273CE, it runs in 14.14 seconds, but if compiled with a long-form zint (which is what ZINT 3 would compile to), hex 030000702614, it runs in 14.7 seconds. So short-form zints are faster than long form zints. I would LOVE to hear an explanation for that, since Christoph's argument to the contrary makes sense to me. RE: HP 49G, 49g+ & 50g: Built-in Zints - Paul Dale - 09-01-2017 11:05 PM If I remember my 28S days correctly, an inline number still executes through the prefix pointer just like an indirect one. I seem to remember an inline object executes extra instructions (those that correspond to the object type number) which act as a fix and nop. I distinctly remember thinking at the time that this was an inspired approach. This would account for inline being slightly slower than indirect. It's been a long time and I'm sure someone will correct me where I'm mistaken. Pauli RE: HP 49G, 49g+ & 50g: Built-in Zints - Christoph Giesselink - 09-01-2017 11:55 PM (09-01-2017 11:05 PM)Paul Dale Wrote: If I remember my 28S days correctly, an inline number still executes through the prefix pointer just like an indirect one. I seem to remember an inline object execute extra instructions (those that correspond to the object type number) which act as a fix and nop. I distinctly remember thinking at the time that this was an inspired approach. Pauli is right, TNX. In the case of Z3_ the RPL interpreter is calling the object directly whereas the inline code object must be decoded by the PRLG utility. In Emu48 CPU cycles Z3_ = ~85 cycles ZINT 3 = ~169 cycles So I'm wrong about the speed. RE: HP 49G, 49g+ & 50g: Built-in Zints - Gerald H - 09-02-2017 08:56 AM (09-01-2017 12:06 PM)Joe Horn Wrote: Those of us who use HP's unmodified extable library can still use your source code if we add equates like these at the top of source code: This does NOT work for the negative integers - ASM refuses to compile. RE: HP 49G, 49g+ & 50g: Built-in Zints - Gerald H - 09-02-2017 10:49 AM OK If you prepend the string below to your source code the programme should compile correctly. Note that the "-" sign in the negative numbers is character 173 on the HP 49G, 49g+ & 50g. The negative sign in eg Z-6_ in the body of your programme must be character 173 . (Or maybe not - Could you please try character 45, the regular minus sign, & see if that works?) "EQU Z-9_ 2733F EQU Z-8_ 2734B EQU Z-7_ 27357 EQU Z-6_ 27363 EQU Z-5_ 2736F EQU Z-4_ 2737B EQU Z-3_ 27387 EQU Z-2_ 27393 EQU Z-1_ 2739F EQU Z0_ 273AB EQU Z1_ 273B6 EQU Z2_ 273C2 EQU Z3_ 273CE EQU Z4_ 273DA EQU Z5_ 273E6 EQU Z6_ 273F2 EQU Z7_ 273FE EQU Z8_ 2740A EQU Z9_ 27416 EQU Z10_ 27422 EQU Z12_ 2742F EQU Z24_ 2743C EQU Z100_ 27449 EQU Z1_0_ 274A9" RE: HP 49G, 49g+ & 50g: Built-in Zints - David Hayden - 09-02-2017 12:23 PM (09-01-2017 11:55 PM)Christoph Giesselink Wrote: In the case of Z3_ the RPL interpreter is calling the object directly whereas the inline code object must be decoded by the PRLG utility.More specifically, when an object is executed directly, the prolog has to readjust the interpreter pointer to point to the following object. The theory of all this is described at the top of page 7 in RPLMAN.doc (http://www.hpcalc.org/details/1743). In practice, it's slightly different. RE: HP 49G, 49g+ & 50g: Built-in Zints - Joe Horn - 09-02-2017 01:12 PM (09-02-2017 10:49 AM)Gerald H Wrote: Note that the "-" sign in the negative numbers is character 173 on the HP 49G, 49g+ & 50g. The following, typed directly on the 50g keyboard, uses character 45 (an ordinary hyphen), and fails to assemble: "EQU Z-9_ 2733F :: Z-9_ ; @" However, if both hyphens are replaced by the character 173 (a "soft hyphen" character in modern fonts), then it does assemble correctly. This is really annoying, since that makes typing these "short form" zints almost impossible on the 50g keyboard. RE: HP 49G, 49g+ & 50g: Built-in Zints - Gerald H - 09-02-2017 01:27 PM Joe, did you try character 173 in the prologue & 45 in the body of the programme? RE: HP 49G, 49g+ & 50g: Built-in Zints - Gerald H - 09-02-2017 01:30 PM Where can I find HP's unmodified extable for 2.15? RE: HP 49G, 49g+ & 50g: Built-in Zints - rprosperi - 09-02-2017 01:52 PM (09-02-2017 01:30 PM)Gerald H Wrote: Where can I find HP's unmodified extable for 2.15? I believe this is the original 2.15 extable. |