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:



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



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.

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?

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:



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.

Include a part in the call that specifies if it's integer or float.

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.

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,...) 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.

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.

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

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

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?

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?

Search for "arbitrary precision" to have your 1000+ digits. And "Newton-Raphson method" to find out doing successive approximations for square roots.

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

http://numbers.computation.free.fr/Constants/Algorithms/representation.html

http://numbers.computation.free.fr/Constants/Algorithms/inverse.html#tth_sEc3