HP Forums
New submission for Saturn assembly version of Math and Trig benchmarks... - 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: New submission for Saturn assembly version of Math and Trig benchmarks... (/thread-12917.html)

New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-03-2019 08:05 PM

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 Smile

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

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

Jonathan Busby

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

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.

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Giuseppe Donnini - 05-03-2019 10:33 PM

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 Tongue

I strongly support that proposal.

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-04-2019 02:56 PM

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

I strongly support that proposal.

Thanks! Big Grin

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

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-04-2019 07:53 PM

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** Smile )

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 Tongue It looks like I forgot to attach the file somehow Smile

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-07-2019 04:33 PM

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

Jonathan

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Giuseppe Donnini - 05-08-2019 12:53 PM

Thanks for enhancing the source code and the documentation!

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-08-2019 04:14 PM

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

You're welcome Smile

Regards,

Jonathan

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-12-2019 08:05 PM

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 Smile

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-13-2019 03:17 PM

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

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-14-2019 03:47 PM

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

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-14-2019 07:25 PM

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

Jonathan

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Werner - 05-15-2019 08:20 AM

(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

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-15-2019 02:47 PM

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

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 Smile 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 Smile

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

Regards,

Jonathan

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-15-2019 04:56 PM

Using the RSTK to save the address of the TIMER2 data backup is such a PITA that's it's not worth it. Smile 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

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Werner - 05-16-2019 07:38 AM

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

That's me, yes ;-)

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-28-2019 04:16 PM

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

Jonathan

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Han - 05-28-2019 11:18 PM

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

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Jonathan Busby - 05-29-2019 03:23 PM

(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! Big Grin Thanks! Smile I think it's also good to see people who are still developing code in Saturn assembly Smile 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 Smile

Regards,

Jonathan

RE: New submission for Saturn assembly version of Math and Trig benchmarks... - Raymond Del Tondo - 05-30-2019 06:09 PM

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