flat assembler
Message board for the users of flat assembler.

Index > Main > FPU Load Float or Int

Author
Thread Post new topic Reply to topic
pal



Joined: 26 Aug 2008
Posts: 227
pal
How do I determine if a number that is stored in memory is an integer or a float value?

For example. I have this code:

Code:
fld1
fist      dword [lOut]
    


I then want to load this within a generic function ex. to take the cosine value of it. So I do:

Code:
fld           qword [lOut]
    


But this will produce a value that i snot the correct value as in lOut we have 1 but we use fld rather than fild. But if I use fild then if I want to pass any float values to the function then it will not work again.

There may be a really easy solution that I do not know of, if some could anyone enlighten me?

Cheers, pal.
Post 11 Oct 2009, 19:54
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
The processor has no way to detect whether a memory portion is a floating point number or an integer.

Could you tell us more about what are you trying to do? Why your cosine function needs to detect the type automagically?


Perhaps this is what you want?
Code:
Int32.cosine:
fild dword [esp+4]
fcos
ret 4

Float.cosine:
fld dword [esp+4]
fcos
ret 4

Double.cosine:
fld qword [esp+4]
fcos
ret 8    
Post 11 Oct 2009, 20:15
View user's profile Send private message Reply with quote
pal



Joined: 26 Aug 2008
Posts: 227
pal
I was making a basic library of math functions, ex. I am working with hyperbolic trig functions, generating algorithms etc, but I want to pass variables to functions. Ex. I was the user to be able to include the file and be able to do something like:

Code:
dbTemp dq 5.0
...
push dbTemp
call cosh
    


But I want them to be able to specify a value that can either be an integer or a floating point. In cases as the above, specifying 5.0 means that I can use fld, but if it is specified as 5 then fild would have to be used.

I realised after I posted that specifying the .0 after the left hand side of the number will work for a lot of ways, but if you do as I said and load 1 then try to save it and reload it you wont get the original value back. Is this just a problem with FPU or am I missing something?

I know in C++ you can do function overrides where it detects the variable type, but I don't know how you would accomplish this in ASM.
Post 11 Oct 2009, 22:18
View user's profile Send private message Reply with quote
windwakr



Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
windwakr
Include a part in the call that specifies if it's integer or float.
Post 11 Oct 2009, 22:30
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Well, I was to post a half solution for your needs but there was a problem: http://board.flatassembler.net/topic.php?t=10752

Note that C++ allows overloading because it is a typed language while Assembly is not so you have to make the static binding yourself. But as you can see in the link it is possible to have something approximate but remember that by no means the CPU will be capable of detecting this, C++ compilers do actually generate specific code for each overload rather than just merging them all and offloading the task to the CPU.
Post 11 Oct 2009, 23:15
View user's profile Send private message Reply with quote
pal



Joined: 26 Aug 2008
Posts: 227
pal
Yeah, macros could possibly do it. I'll have to find out how they are assembled on the go, although I think for now I will leave it up to the callee code to make sure that a float is being passed. I could also have a parameter specifying whether a variable is a float or not (cosh(QWORD lpIn,BOOL bFloat,...)Wink and then do a simple check and use fild/fld accordingly.

Also, I know that you have to make separate functions for overloading, but the compiler chooses what goes where. I guess that is one advantage to higher level languages.
Post 12 Oct 2009, 15:17
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
If all the functions are small like this cosine example, then they should be inlined with a macro anyways. no point in having the call and return overhead for 2/3 opcodes.
1 - Push argument memory to FP stack
2 - FP operation
3 - Pop result from FP into the argument memory location OR have the caller handle 3.
Post 12 Oct 2009, 17:29
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
pal



Joined: 26 Aug 2008
Posts: 227
pal
That is a true point actually. Plus I was saving the contexts of the FPR before I did it. I guess that is a problem with libraries though as well (well some libraries).
Post 12 Oct 2009, 18:20
View user's profile Send private message Reply with quote
Remy Vincent



Joined: 16 Sep 2005
Posts: 155
Location: France
Remy Vincent
pal wrote:
That is a true point actually. Plus ...


I have been very interested in some kind of research about cosine drawing, and it wasn't funny to wait the WHOLE DRAWING to view something about whole cosine points.

So remember I was able to draw SOME POINTS then more POINTS a little while after refreshing the points. So there is the result, I was not only able draw points, but I forget about the other stuff I was coded then ...

Even with a VERY SLOW computer, the drawing was all ok after less than only 60 points, or even less!!

But the algorithm is still in pascal, so I would'nt post this pascal code on project/idea topics ; BUT I understand that it could be some kind of funny to translate the SOME POINTS drawing algorithm from pascal to assembler, and also it would shorter it in assembler ( 300 asm lines < 350 pascal lines ) ...


Description: The result at the end of the SOME POINTS algorithm drawing, ...
Filesize: 21.28 KB
Viewed: 2901 Time(s)

MinimathAllPt.jpg


Description: The result after only SOME POINTS algorithm drawing, ...
Filesize: 32.95 KB
Viewed: 2902 Time(s)

MinimathSomePt.jpg


Post 12 Oct 2009, 20:10
View user's profile Send private message Visit poster's website Reply with quote
pal



Joined: 26 Aug 2008
Posts: 227
pal
Is that program your own? I could not find it on Google so I presume it is?

Any chance of posting the pascal code up? Although I am no pascal expert, pascal is pretty straight forward and I would like to have a look at that code/have a go at converting it to assembly.

The only problem I can see is that graphing window, unless I have you mistaken or there is a control for it then surely that will take quite a few lines of code to generate. Or does the program emulate pascal code or what?
Post 12 Oct 2009, 20:34
View user's profile Send private message Reply with quote
pal



Joined: 26 Aug 2008
Posts: 227
pal
Since I have another question (and I decided I didn't want to do what asmcoder did and start a million threads) and it is kinda related.

Basically I was wondering what the best approach to finding a number, for example a square root, was to a very precise amount of digits ex. 1000+. The FPU approach only allows for accuracy in an FPR up to 19 significant digits which, unless you can do a huge array of instructions somehow, is obviously not accurate enough. Is my only approach using BCDs?

Surely there must be a better method than that? If there is not what is the point of the FPU? Just to make things easier as there is no real practical application of having a square root of a number to 1000+ decimal places or what? I know BCD came in before the FPU came in, and obviously packed BCD was quite advantageous, but what are the comparisons like now?
Post 12 Oct 2009, 22:28
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17251
Location: In your JS exploiting you and your system
revolution
Search for "arbitrary precision" to have your 1000+ digits. And "Newton-Raphson method" to find out doing successive approximations for square roots.
Post 12 Oct 2009, 22:30
View user's profile Send private message Visit poster's website Reply with quote
Remy Vincent



Joined: 16 Sep 2005
Posts: 155
Location: France
Remy Vincent
It would be really hard to find a really big big book with 100% of the information about calculating digits.

How could you have a look at the previous page or even at the next page, inside those kind of big big book about digit calculation ... it's to hard to read information written from previous century!! they don't write with our words, they don't explain digit calculation with our grammar!! It's proved that all digit calculations of previous century are not readable anymore by us!

Then we need to start from scratch each new century, at least about digit calculation. The problem is that all countries, not only china or russia, are planning to read digit calculations of previous century or even digit calculations of the century before the previous century, and we know that this is absurd!! So, after discussing and discussing, and discussing again, we just need mining monkeys, That is the point ...

_________________
Groups lower your IQ
Post 12 Oct 2009, 23:46
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17251
Location: In your JS exploiting you and your system
revolution
Post 12 Oct 2009, 23:58
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.