This is the latest info that Ray has sent to me on the library that he is writing.

Proposed list of functions for Fpu.lib:

Conversion functions:
FpuAtoFL Convert Alphanumeric to REAL10
FpuFLtoA Convert REAL10 to Alphanumeric

Arithmetic functions:
FpuAdd Add 2 numbers
FpuSub Subtract 2 numbers
FpuMul Multiply 2 numbers
FpuDiv Divide 2 numbers
FpuSqrt Extract square root of a number
FpuXexpY Raise a number to an exponent
FpuAbs Returns the absolute value of a number
FpuTrunc Discards the decimal portion of a number
FpuRound Rounds a number to the nearest integer

Trigonometric functions:
FpuSin Sine of an angle
FpuCos Cosine of an angle
FpuTan Tangent of an angle
FpuArcsin Angle corresponding to a sine
FpuArccos Angle corresponding to a cosine
FpuArctan Angle corresponding to a tangent

Hyperbolic functions:
FpuSinh Hyperbolic sine of a number
FpuCosh Hyperbolic cosine of a number
FpuTanh Hyperbolic tangent of a number
FpuArcsinh Number corresponding to a hyperbolic sine
FpuArccosh Number corresponding to a hyperbolic cosine
FpuArctanh Number corresponding to a hyperbolic tangent

Logarithmic functions:
FpuLnx Napierian logarithm of a number
FpuLogx Base 10 logarithm of a number

Miscellaneous functions:
FpuExam Checks REAL10 for zero, sign, and absolute value less than 1
FpuSize Returns the exponent as would appear in scientific notation

Proposed flexibility:
- Decimal strings in regular format or scientific notation will be allowed
for conversion to REAL10.
- Regular format or scientific notation, and the number of decimal digits
will be allowed to be specified when converting from REAL10.
- REAL10, LONG integers, and the FPU constants will be allowed as input
wherever appropriate.
- Angle in degrees or radians will be allowed as input (or output) for the
trigonometric functions.
- Results will be allowed to remain on the FPU or stored in memory wherever

Necessary restriction:
- Only one result will be allowed to remain on the FPU to be used
immediately with the following function.

Other restrictions:
- The total number of digits (including leading 0's) is limited to 18 in a
string to be converted to a REAL10.
- The total number of digits returned when converting from a REAL10 to a
string is limited to 16.

Posted on 2002-12-02 06:02:42 by hutch--
Just my first impression, but is it really worth implementing functions such as Add and Subtract for the obvious reason that you are wrapping an entire procedure round a single instruction.

I realise that you can reply with, "just cause its there, its doesn't have to be used" and if someone is willing to stick the effot in to do it, I have no problem with that.

But maybe a sensible compromise would be to use macros to implent the librarys functions (if it is nesscery for a function to be used such with as the FpuExam function (Use macros all round to maintain some sort of calling consistantcy)) , otherwise the macro could directly handle the task, such as adding two numbers.

Just my quick first up thoughts
Posted on 2002-12-05 03:37:32 by huh
I think that it's time for me to get involved directly in this forum.

First, the MAIN intent of the Fpulib is to provide a series of functions which will allow beginners in assembly programming to perform high precision maths before learning any of the intricacies and syntax of the FPU.

When they become more familiar with assembly, they could then expand their knowledge to the FPU instructions. The commented source code for the Fpulib functions can then be used for learning and later streamlining their code.

I do agree that a function like FpuAdd for adding two numbers may seem trivial to persons familiar with programming the FPU. However, to the uninitiated, there is a lot more to it than the simple "fadd" instruction.

One has first to learn how to load the FPU registers with the two numbers, instructions being different for REAL and integer numbers, AND an indirect method must be used to load immediate numbers or the content of the CPU registers.

One must also learn how to detect invalid operations such as could result even with the "fadd" instruction if one of the numbers is an undetected NAN carried over from a previous operation. Then, one has to learn how to transfer the result to memory, instructions being different for REAL and integer variable types. It may also be preferable to leave the result on the FPU.

The Fpulib would make all these details transparent to the beginner (as with most high level languages). The only requirement would be to check the return value in EAX for the error code indicating an invalid operation.

Overall, I would have a lot of difficulty incorporating all of the potential variables into a single properly working macro which would cover all situations!!! Furthermore, if such a complex macro is feasible, the entire macro code gets repeated in the assembled program every time the addition of two numbers (or other operation) is required, instead of only once when written as a procedure.

A few more functions have been added to the list since the first posting. One is the FpuComp for comparing 2 numbers, another is the FpuChs to change the sign of a number. Also, the antilog functions FpuEexpX (e^x) and FpuTexpX (10^x) have been added; although the FpuXexpY (x^y) function could have been used, the new ones require one less parameter to be passed and are more efficient.

FYI the library is effectively completed and the related Help file is almost completed. Remains the tedious task of testing each function thoroughly to insure proper performance under all the conditions enumerated in the Help file. Any volunteers for beta testing????

Posted on 2002-12-08 16:20:15 by Raymond
Hi Raymond,

I agree with you on the "teaching" usefullness of the library, before
anything else. Coders can customize their code if needed, anyway.. and
beginners may benefit from the huge number of functions and the clear
way they're written.

Just a thought.. you felt limited by the MACROs, which in the hands of
geniuses like bitRAKE can be very powerful tools, but can't do all the
miracles one needs anyway.

So I'd like to propose a simple, common for us all, preprocessor. If we
all agree, it could be nice, and could be easily added to our assemblers
via batch files.

Basically it would get in input asm sources, identify some key words,
pass as-is every text non identified, and instead expand the key words.
How would it expand the key words?

Well, I thought about this: let our preprocessor program's name be
PPAsm (PreProcessAsm, or any other name we wish of course), it will
have a plug-ins directory. Each plug-in will identify one (or more)
keywords, and will contain a little program to expand them.

Not as powerful as a compiler (which would be able to track the nearby
instructions to produce better code), but quite powerful. Imagine
something like this:

MOV ...
ADD ...

Where MEMCPY.MM gets expanded by some plug-in into code to perform a
memory copy between misaligned regions of memory.



Which generates optimized code (not the usual unoptimized list of
PUSHes as the INVOKE macro does).



To perform "magic division" (as the tool The Svin created), generating
quick code to divide EAX by the constant 142, using EBX as temp register,
and will expand the line above to:

MOV EBX,3871519816

I'm sure that all the geniuses we have here would produce tons of useful
plugins that will expand this system in very useful ways; you could, for example,
produce some good FPU support.

We could then specify the target assembler (MASM/TASM/FASM,etc..) for a
common code formatter (also to work in memory not with text, but with data
easier to manipulate), and other info, if necessary, inside the batch file, e.g.:


It would use the code formatter MyASM found in its directory Formatters.
The plug-ins may be either 32 bit binary files made with a small header
to import/use some functions from the main program, or whole EXE's.
Posted on 2002-12-09 02:54:12 by Maverick