Well, heres the product of too much free time (which I don't actually have :confused: ). Gods know what you'll use them for, I certainly can't think of a use for 90% of them :grin: but hopefully they'll make a nice addition to our library of functions.

Note that in the intrest of allowing us to easily compile eachothers sources I'd suggest everyone put this in their Masm32 MACROs folder. But its up to ye.

Credit should go to this site, my vb help file and to bitRAKE who demonstrated a nice optimisation for the fscale instruction.
Posted on 2002-02-08 18:27:42 by Eóin
Great compilation. Are there any dependancies on the rounding mode, or restrictions on the parameters? What are the outcomes if the parameters are out of range? These will come in handy. Could easily whip up a little calculator.

Thanks for sharing! :alright:
Posted on 2002-02-08 20:05:26 by bitRAKE
Thanks bitRAKE, There shouldn't be any dependancie on rounding mode, only the exponential macros use rounding at all and your MACRO works regardless of rounding.

The only parameter restrictions should be the restrictions of the actual funtion, of example ArcCos will only give a proper answer if the parameter is from -1 to 1.

Also there was one thing I forgot to make clear, if function takes one parameter the it takes it in st and returns the answer in st, st1 will remain exactly as it was, although the last few st's may be lost.
If a function takes two parameter it takes them from st and st1 and returns the answer in st. What was in st2 will end up in st1.

Also I believe bitRAKE, you mentioned, regarding the exp MACRO X has to be in range +/-16000 IIRC?. So in theory this could be a problem as I used that code for all exponential functions. :(

Perhaps I should have used some conditional assembly to offer people a choice.


fPow2 MACRO ; 2^st, 98 clocks
sub esp,16
fist dword ptr
fstp tbyte ptr
fisub dword ptr
mov eax,
add ,eax
fld tbyte ptr
add esp,16


fPow2 MACRO ; 2^st
fld st
fsub st(1),st
fstp st


With the second fPow2 function there would be no limit on the range.
Posted on 2002-02-09 07:39:48 by Eóin
That limitation is due to the limitations of REAL10 - anything outside that range would be +/-infinity. Unfortunately, the function doesn't return +/-infinity when it should. :(
Posted on 2002-02-09 09:39:19 by bitRAKE