New submission for Saturn assembly version of Math and Trig benchmarks...

[Jonathan Busby]

I've written new HP48G/GX-R Saturn assembly versions of the "math" and "trig" benchmarks corresponding to the benchmarks listed on the benchmarks page. I've attached them in a zip file. They're in plain ASCII text with no tabs and written using Jazz / HP Tools syntax. I've also attached the HP48G/GX-R binaries in a separate archive.

The results I got for the math benchmark were :

• Final value of "R2" is : 9427
• The value of the computation is : 1.25345460548104
  
  

The results I got for the trig benchmark were :

• Final value of "R2" is : 807
• The value of the computation is : 0.28866776461625
  
  

According to the above, the "math" speedup of a 3.9MHz HP48G/GX over the HP 9100A is about : 1388.36% , which is huge

For the "trig" benchmark the speedup is, again, huge and is 2017.5%

If anyone finds this data helpful then perhaps the curator can add it to the benchmarks page

Jonathan Busby

EDIT : I had to delete and re-upload the benchmarks binaries as I forgot
to include the README.txt file

EDIT #2 : The latest, and faster refactored version of the code, complete with build system and files, source and binaries can be found here as an attachment to this post.

[Giuseppe Donnini]

Thanks, Jonathan! I really enjoyed reading your code.

(05-03-2019 08:05 PM)Jonathan Busby Wrote:  If anyone finds this data helpful then perhaps the curator can add it to the benchmarks page

I strongly support that proposal.

[Jonathan Busby]

(05-03-2019 10:33 PM)Giuseppe Donnini Wrote:  Thanks, Jonathan! I really enjoyed reading your code.

(05-03-2019 08:05 PM)Jonathan Busby Wrote:  If anyone finds this data helpful then perhaps the curator can add it to the benchmarks page

I strongly support that proposal.

Thanks!

I didn't optimize the code space-wise much. Also, I didn't bother with small speed optimizations such as using a "GONC" instead of a "GOTO" because of the law of diminishing returns as applied to the fact that the HP48 floating point math entry points take up so much time that it wouldn't really matter. I may upload a new version of the code that is a little more cleaned up and is slightly smaller and ever so slightly faster.

Regards,

Jonathan

[Jonathan Busby]

After cleaning up the code somewhat the results for the math and trig benchmarks are, respectively :

• "R2" is 9489 which is a 1397.49% speedup
• "R2" is 807 which is a 2017.5% speedup
  

( the numeric results are the same. **Make sure your calc is in RAD mode** )

I've attached an archive which contains everything needed to build the benchmark code and I've also included the benchmark binaries in the archive.

Regards,

Jonathan

EDIT: Oops It looks like I forgot to attach the file somehow

[Jonathan Busby]

The latest incarnation of the benchmark code is attached, and, it should show up on hpcalc.org soon

Jonathan

[Giuseppe Donnini]

Thanks for enhancing the source code and the documentation!

[Jonathan Busby]

(05-08-2019 12:53 PM)Giuseppe Donnini Wrote:  Thanks for enhancing the source code and the documentation!

You're welcome

Regards,

Jonathan

[Jonathan Busby]

Just re-worked the code and the ( hopefully ) final version is attached, which I just uploaded to hpcalc.org.

Jonathan

EDIT : The code attached to this post has a subtle but *nasty* little bug which could cause a TTRM. *Don't* run it

[Jonathan Busby]

The code contains a small bug that doesn't affect its operation. Specifically, the code is self modifying and writes the saved TIMER2 value to RAM pre-allocated within a CODE object, which means that its CRC changes every time it's run. I'm updating the code to zero out the 8-nibble RAM variable after it's been retrieved for the process of restoring the system time. I'll be uploading the fixed code later today, as an attachment and to hpcalc.org .

Jonathan

[Jonathan Busby]

(05-12-2019 08:05 PM)Jonathan Busby Wrote:  Just re-worked the code and the ( hopefully ) final version is attached, which I just uploaded to hpcalc.org.

Jonathan

Well, I highly advise *against* running the attached code. It has a subtle but nasty little bug which I'm surprised didn't cause my calculator to eat itself . Specifically, when juggling the hardware return stack, I made the following error :

Code:

saveTimeandInit
...

    GOSUB   +               * Push address of the next 8 nibble to the return stack
    BSS     8               * Reserve 8 nibbles of RAM to save the current TIMER2 value
+   C=RSTK                  * Get address of TIMER2 RAM save area from the return stack
...

That is, the top level of the RSTK gets a *data* address pushed to it and then when the RTN at the end of the subroutine is called, it "returns" to that address. The solution is to replace the above code with this :

Code:

    D0=(5) =IRAMBUFF
    DAT0=C WP

For some reason I became obsessed with how to juggle the registers between the RSTK, D and C, when I had two 20-bit values and one 32-bit value, without using any other registers. Well, there is an easy fix for the code that uses IRAMBUFF, as shown above. I'll include the fixed version as an attachment and upload it to hpcalc.org later today.

Jonathan

[Jonathan Busby]

And here is version 0.2.3a Hopefully it's not buggy

Jonathan

[Werner]

(05-14-2019 03:47 PM)Jonathan Busby Wrote:  I made the following error :

Code:

saveTimeandInit
...

    GOSUB   +               * Push address of the next 8 nibble to the return stack
    BSS     8               * Reserve 8 nibbles of RAM to save the current TIMER2 value
+   C=RSTK                  * Get address of TIMER2 RAM save area from the return stack
...

That is, the top level of the RSTK gets a *data* address pushed to it and then when the RTN at the end of the subroutine is called, it "returns" to that address.

? No, because you get it off the stack with C=RSTK, and the RTN at the end of the subroutine will return to the previously pushed address. Unless you exhausted the 8 levels, I see no error here. But it's been a while, admittedly.
Cheers, Werner

[Jonathan Busby]

(05-15-2019 08:20 AM)Werner Wrote:  

(05-14-2019 03:47 PM)Jonathan Busby Wrote:  I made the following error :

Code:

saveTimeandInit
...

    GOSUB   +               * Push address of the next 8 nibble to the return stack
    BSS     8               * Reserve 8 nibbles of RAM to save the current TIMER2 value
+   C=RSTK                  * Get address of TIMER2 RAM save area from the return stack
...

That is, the top level of the RSTK gets a *data* address pushed to it and then when the RTN at the end of the subroutine is called, it "returns" to that address.

Well, I forgot to mention that I later *push* the value in C.A back onto the RSTK It's used by the system time restore code later. The problem is that the GOSUB is called within a subroutine, which is also called via a GOSUB. I tried juggling the RSTK levels, and, although I could get them in the correct order ( ie. return address on top ), in the process I had to clobber D.W and C.W which clobbered the read TIMER2 value

Quote:? No, because you get it off the stack with C=RSTK, and the RTN at the end of the subroutine will return to the previously pushed address. Unless you exhausted the 8 levels, I see no error here. But it's been a while, admittedly.
Cheers, Werner

Well, the IRAMBUFF solution is much simpler so I chose to go with that It's also simpler in that the code is not self-modifying and I don't have to zero out 8-nibbles at the end of the code

If you're the the Werner with whom I corresponded often back in the day on comp.sys.hp48, then long time no see Otherwise, nice to meet you anyway

Regards,

Jonathan

[Jonathan Busby]

Using the RSTK to save the address of the TIMER2 data backup is such a PITA that's it's not worth it. Because I had to preserve the long real in A.W and B.W, the only registers I had to work with were D.W , C.W , D0 , D1 and I also had the RSTK. The problem is that the TIMER2 value is 32-bits and I couldn't find a way of juggling the above regs including the RSTK without clobbering that, or at least part of it ( R4.W is used as a counter and R0.W through R3.W are all clobbered by the HP48 ROM 15-digit BCD floating point math routines. ).

Regards,

Jonathan

[Werner]

(05-15-2019 02:47 PM)Jonathan Busby Wrote:  If you're the the Werner with whom I corresponded often back in the day on comp.sys.hp48, then long time no see

That's me, yes ;-)

[Jonathan Busby]

And it's now on hpcalc.org : https://www.hpcalc.org/details/9016

Jonathan

[Han]

Good to see that there are folks who still prefer the HP syntax as opposed to the MASD syntax.

[Jonathan Busby]

(05-28-2019 11:18 PM)Han Wrote:  Good to see that there are folks who still prefer the HP syntax as opposed to the MASD syntax.

HA! Thanks! I think it's also good to see people who are still developing code in Saturn assembly I prefer HP Tools / Jazz syntax as I want maximum verbosity to stave off any would be bugs, especially corner cases and off-by-one errors. Also, I've been programming in Saturn assembly since 1995 in HP Tools / Jazz syntax and I know it like the back of my hand, so, MASD syntax would not be intuitive to me

Regards,

Jonathan

[Raymond Del Tondo]

(05-28-2019 11:18 PM)Han Wrote:  Good to see that there are folks who still prefer the HP syntax as opposed to the MASD syntax.

Of course there are:-)
MASD syntax, especially the pseudo-macro type words, was (maybe) nice for small displays like the HP 48 LCD.
In MASD, some loop constructs and maybe other things are heavily simplified,
at least optically.

However when disassembling code assembled using MASD, the result could be very far away from what you would expect.

Not my thing.