HP 49G, 49g+ & 50g: Built-in Zints

[Gerald H]

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
2734B    (Z-8)    -8
27357    (Z-7)    -7
27363    (Z-6)    -6
2736F    (Z-5)    -5
2737B    (Z-4)    -4
27387    (Z-3)    -3
27393    (Z-2)    -2
2739F    (Z-1)        -1
273AB    (Z0)        0
273B6    (Z1)        1
273C2    (Z2)        2
273CE    (Z3)        3
273DA    (Z4)        4
273E6    (Z5)        5
273F2    (Z6)        6
273FE    (Z7)        7
2740A    (Z8)        8
27416    (Z9)        9
27422    (Z10)    10
2742F    (Z12)    12
2743C    (Z24)    24
27449    (Z100)    100
274A9    (ZINT1_0)    ( 1 0 )

[Joe Horn]

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.)

[Gerald H]

Yes, that works as you have it, not reversed.

[rprosperi]

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?

[Gerald H]

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/h...ntries.pdf

[rprosperi]

(09-01-2017 03:42 PM)Gerald H Wrote:  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/h...ntries.pdf

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.

[DavidM]

(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.

Thanks again for sharing this.

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.

[Christoph Giesselink]

(09-01-2017 09:18 AM)Gerald H Wrote:  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.

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:

    
* ZINT 0
    CON(5)    =DOINT
    CON(6)    6
    
* ZINT 8
    CON(5)    =DOINT
    CON(5)    7
    NIBHEX    80

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.

[Gerald H]

Concerning timings you are wrong.

On a 50g timing this programme

Code:

« 1 10000
  START Z3 DROP
  NEXT
»

with

Code:

::
  x<<
  Z3_
  x>>
;

as Z3 took

25.9489s

with

Code:

::
  x<<
  ZINT 3
  x>>
;

as Z3 took

26.9957s

[Gerald H]

& on a 49G, OS 1.19-6

Z3_ time 79.1s

ZINT 3 time 81.1s

[Joe Horn]

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.

[Paul Dale]

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

[Christoph Giesselink]

(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.

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

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.

[Gerald H]

(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:

EQU Z0_ 273AB

... right? (Or must the address be nibble-reversed? I can never remember.)

This does NOT work for the negative integers - ASM refuses to compile.

[Gerald H]

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"

[David Hayden]

(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.

[Joe Horn]

(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 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?)

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.

[Gerald H]

Joe, did you try character 173 in the prologue & 45 in the body of the programme?

[Gerald H]

Where can I find HP's unmodified extable for 2.15?

[rprosperi]

(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.