Post Reply 
question for hppl compiler people
11-13-2017, 10:20 AM
Post: #1
question for hppl compiler people
If I declare a variable as:

LOCAL A:=#0d32;

vs

LOCAL A:=0.;

Does the first declaration result in operations involving such variables being compiled to integer operations and the second declaration result in operations compiled to floating point operations?

....or...is everything converted to a common format (like real or int) and everything done using that format?

I was trying a few operations in a big loop and the timing seems to be the same regardless of the declaration, which probably means it's all done in floating point format since there isn't a hardware FPU in the ARM chip....integer would be faster if there was a difference.

Let me know if any of you are familiar with the compiler internals...
Thx
-Donald
Find all posts by this user
Quote this message in a reply
11-13-2017, 11:04 AM
Post: #2
RE: question for hppl compiler people
(11-13-2017 10:20 AM)webmasterpdx Wrote:  integer would be faster if there was a difference.
-Donald

You've answered your own question!

Tom L
Cui bono?
Find all posts by this user
Quote this message in a reply
11-13-2017, 02:58 PM
Post: #3
RE: question for hppl compiler people
You have what is called HP_Real values internally which are BCD encoded floats. Then you have HP_Int which is an integer encoded 64 bit object.

HP_Int will most likely be slightly faster, but to the point of negligence. There are generally more checks and Reals will be checked for and handled first in the trees.

TW

Although I work for HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
11-14-2017, 10:09 AM
Post: #4
RE: question for hppl compiler people
I guess I'm asking can we through declaration, control which is being used? e.g. Lets say it's using floats by default and I want to do some numeric search/algorithm using bytes only, so I define a variable as #0d8 or something like that. Is there a way to speed up the algorithm by forcing integer instead of float arithmetic?
Thx
Find all posts by this user
Quote this message in a reply
11-14-2017, 03:57 PM
Post: #5
RE: question for hppl compiler people
Both TYPE(0.) and TYPE(0) return 0 (HP_real) whereas TYPE(#0d) returns 1 (HP_int)

So you already have a mechanism for declaring the types.

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
11-14-2017, 08:58 PM
Post: #6
RE: question for hppl compiler people
(11-13-2017 02:58 PM)Tim Wessman Wrote:  You have what is called HP_Real values internally which are BCD encoded floats. Then you have HP_Int which is an integer encoded 64 bit object.

HP_Int will most likely be slightly faster, but to the point of negligence. There are generally more checks and Reals will be checked for and handled first in the trees.

Tim, I am sure you meant negligibility Smile

Stephen Lewkowicz (G1CMZ)
https://my.numworks.com/python/steveg1cmz
Visit this user's website Find all posts by this user
Quote this message in a reply
11-15-2017, 05:11 AM
Post: #7
RE: question for hppl compiler people
Han, so when I have:

LOCAL A:=#0d32;

etc.. Then if I have an algorithm using such variables, can I assume it's using integer arithmetic?
I'll try to create a test of this when I get a chance and implement it in a loop with both floats and integers....ideally I should get different results.
My previous test just called PIXON_P to fill the screen. It's possible that that isn't enough....I'll try to create just a few arithmetic statements and avoid the function calls. There is an obvious conversion on a function call that makes the water murky.
Find all posts by this user
Quote this message in a reply
Post Reply 




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