New submission for Saturn assembly version of Math and Trig benchmarks...
05-03-2019, 08:05 PM (This post was last modified: 05-18-2019 04:32 PM by Jonathan Busby.)
Post: #1
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
New submission for Saturn assembly version of Math and Trig benchmarks...
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

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.

Attached File(s)

Aeternitatem modo est. Longa non est, paene nil.
05-03-2019, 10:33 PM
Post: #2
 Giuseppe Donnini Member Posts: 73 Joined: Feb 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...

(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.
05-04-2019, 02:56 PM
Post: #3
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
(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

Aeternitatem modo est. Longa non est, paene nil.
05-04-2019, 07:53 PM (This post was last modified: 05-05-2019 12:14 AM by Jonathan Busby.)
Post: #4
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
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

Attached File(s)

Aeternitatem modo est. Longa non est, paene nil.
05-07-2019, 04:33 PM
Post: #5
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
The latest incarnation of the benchmark code is attached, and, it should show up on hpcalc.org soon

Jonathan

Attached File(s)

Aeternitatem modo est. Longa non est, paene nil.
05-08-2019, 12:53 PM
Post: #6
 Giuseppe Donnini Member Posts: 73 Joined: Feb 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
Thanks for enhancing the source code and the documentation!
05-08-2019, 04:14 PM
Post: #7
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
(05-08-2019 12:53 PM)Giuseppe Donnini Wrote:  Thanks for enhancing the source code and the documentation!

You're welcome

Regards,

Jonathan

Aeternitatem modo est. Longa non est, paene nil.
05-12-2019, 08:05 PM (This post was last modified: 05-14-2019 03:49 PM by Jonathan Busby.)
Post: #8
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
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

Attached File(s)

Aeternitatem modo est. Longa non est, paene nil.
05-13-2019, 03:17 PM
Post: #9
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
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

Aeternitatem modo est. Longa non est, paene nil.
05-14-2019, 03:47 PM
Post: #10
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
(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

Aeternitatem modo est. Longa non est, paene nil.
05-14-2019, 07:25 PM
Post: #11
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
And here is version 0.2.3a Hopefully it's not buggy

Jonathan

Attached File(s)

Aeternitatem modo est. Longa non est, paene nil.
05-15-2019, 08:20 AM
Post: #12
 Werner Senior Member Posts: 426 Joined: Dec 2013
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
(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
05-15-2019, 02:47 PM
Post: #13
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
(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

Aeternitatem modo est. Longa non est, paene nil.
05-15-2019, 04:56 PM (This post was last modified: 05-15-2019 05:10 PM by Jonathan Busby.)
Post: #14
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
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

Aeternitatem modo est. Longa non est, paene nil.
05-16-2019, 07:38 AM
Post: #15
 Werner Senior Member Posts: 426 Joined: Dec 2013
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
(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 ;-)
05-28-2019, 04:16 PM
Post: #16
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
And it's now on hpcalc.org : https://www.hpcalc.org/details/9016

Jonathan

Aeternitatem modo est. Longa non est, paene nil.
05-28-2019, 11:18 PM
Post: #17
 Han Senior Member Posts: 1,817 Joined: Dec 2013
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
Good to see that there are folks who still prefer the HP syntax as opposed to the MASD syntax.

Graph 3D | QPI | SolveSys
05-29-2019, 03:23 PM (This post was last modified: 05-29-2019 03:31 PM by Jonathan Busby.)
Post: #18
 Jonathan Busby Member Posts: 119 Joined: Nov 2014
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
(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

Aeternitatem modo est. Longa non est, paene nil.
05-30-2019, 06:09 PM
Post: #19
 Raymond Del Tondo Member Posts: 248 Joined: Dec 2013
RE: New submission for Saturn assembly version of Math and Trig benchmarks...
(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.

-- Ray
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)