News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Question Concerning FPU Code

Started by Fred Harris, January 27, 2016, 04:10:23 PM

Previous topic - Next topic

Fred Harris

In my masm32 installation there is an fpulib subdirectory with source and lib files.  Here's my problem.  I'm trying desperately to eliminate linking with the C Runtime (LIBCMT) so as to minimize executable size of my C++ code.  Its working spectacularly with one fatal flaw.  No matter what I try I am unable to perform any type of window/console/file output involving floating point numbers.  I'm able to use the variable arguement printf family of functions through simpler replacements for them so as to prevent use of the functions in the C Runtime.  Also, there are replacements for a lot of printf functionality in Win32, so that's been a big help.  But there seems to be no replacement for printf style floating point functionality without the C runtime.  As an example, just attempt to output a double with Windows wvsprintf().  Believe me, I tried.  It doesn't work.  And there are a lot of strange new Windows functions such as this one...

StringCchPrintf()

And it seems to work.  However, when I attempt to incorporate it into my code without the C Runtime, i.e., /NODEFAULTLIB - which eliminates the C Runtime, it won't work.  It apparently is just a wrapper function around  vprintf or whatever.  The conclusion I have come to, if I want to persist in my endeavor to minimize code size through elimination of the C runtime, is that I'm going to have to come up with my own fpu code and routines to convert floating point numbers to a string representation which can be output.

I see that your own Raymond Filiatreault has produced that fpu code.  FpuFLtoA seems to be what  need.  Would it be possible for me to link against that library code do you think?????  I believe Hutch said libs produced by masm are COFF files callable from C/C++???  I'd love to hear some thoughts on this!

What I'm doing I learned from an old Matt Pietrek article in Microsoft Systems Journal about reducing executable size by eliminating the C runtime.  Basically what one does is provide very basic stripped down versions of some required start up code, and it works wonderfully!  Let me just give an example.  I have written my own C++ String Class which compiles much smaller than the string class in the C++ Standard Library.  Basically like half the size.  But with VC9 from Visual Studio 2008 we're still looking at like a 60k "Hello, World!" executable.  With Matt's LibCTiny.lib I'm down to 6 k!  A ten fold decrease!!!  But if I can't beat this floating point issue I'm done for!
 


hutch--

Fred,

I would be looking at Ray's "fpu.lib" which also has the MASM format prototypes in the same directory. You will need to write your own C/C++ prototypes if you are going to call that lib from C/C++ and from memory the format is EXTERN but you will have to look up the C notation as I am a bit rusty in that area. They are all STDCALL functions.

GoneFishing

StringCchPrintf belongs to Strsafe family of functions .  They reside in strsafe.h , a header with code . There were some debates about these functions on the forum.   

Fred Harris

Thanks Hutch and GoneFishing.  If you go fishing around here now its going to have to be ice fishing!

From your replies its sounds like I'm on the right track.  I saw those masm prototypes in the inc file of the /fpulib directory, and I can generate C conversions for them.  Today I'll work on trying to do that and calling them from masm and C/C++.  I'd really love to accomplish that.  As an aside, any chance there are 64 bit versions of Ray's fpu code available?

qWord

Quote from: Fred Harris on January 28, 2016, 02:48:58 AMI saw those masm prototypes in the inc file of the /fpulib directory, and I can generate C conversions for them.
Remarks that not all compiler supports x87 long double (e.g. Microsofts Toolchain), so you can then only work with the memory operands of the fpulib functions. Furthermore, MSVC/Windows does set the FPU precision to 53 Bits, so all fpulib-operations will also be done with that precision ( and not with 64 Bit as you probably expect).

Quote from: Fred Harris on January 28, 2016, 02:48:58 AMAs an aside, any chance there are 64 bit versions of Ray's fpu code available?
AFAIK there is no 64 Bit version.
MREAL macros - when you need floating point arithmetic while assembling!

raymond

QuoteAs an aside, any chance there are 64 bit versions of Ray's fpu code available?

The answer is definitely no. The only occasion I could think of to need the 64-bit would be if you were doing computations with 64-bit integers. i.e. integers exceeding 4,294,967,295; those would be really big numbers. Remember that a 64-bit linker allows all 32-bit assembly instructions.

Mind you, even though my MASM linker only allows 32-bit integers,  I have written short programs requiring computations with 64-bit integers but by using the FPU which has the full accuracy of 64 bits IF you set the precision of the FPU to extended double precision.

As for using external functions for printing floats, you could use the Fpulib's FpuFLtoA function for the actual conversion from float to alphanumeric and then simply print the returned string whose actual address is returned in the EAX register.
Whenever you assume something, you risk being wrong half the time.
http://www.ray.masmcode.com