Hi All,

DDK says that "Floating point arithmetic is not otherwise supported in the Windows NT kernel code."
but i was able to execute a small piece of code which does float operations.

VOID Floatops()
{
int decimal, sign;
char *buffer;
double a = 22.00,b = 7.0,c=0;
c = a/b;
buffer = _fcvt( c, 7, &decimal, &sign ); // uses libc.lib for linking
KdPrint(( "Value: '%s' Decimal: %d sign: %d\n",buffer, decimal, sign ));
}

which neatly calculcated the value.To fix the linking issues i said
extern int _fltused = 0;

I just wanted to know

1.what are the implications of doing such a thing,do the float values get corrupted over time
i.e due to some other operations

2.Do i have to use the KeSaveFloatXXX and Restore routines,to perform float operations in a "safe" way.

3.When I say "extern int _fltused =0;" ,is it a valid thing to do.what is _fltused ?? where does it come from,
what is being linked that uses this

Regards,
Manohar

1'st off: Plain text (not HTML) is normally the order of the day in
newsgroups.

To answer your question, the main issue at stake here is that a great deal
of kernel code executes in arbitrary thread context. Floating point code
sets status and tag bits in the FP registers, and may additionally change
the floating point control word. So, if you execute floating point code, and
do not correctly save and restore the FPU state, then floating point code in
user applications may show undefined behaviour.

To add to the above set of amusements, not only do you have to save and
restore floating point state when executing in arbitrary thread context, but
also, in kernel mode, it's an exceedingly good idea to set the FP control
word so that the FPU does not raise exceptions, but instead returns NaN
results. You must, of course, then error check the results appropriately.

So, answering your questions:

In your example, yes, there is the possibility for "interference".


Yes, you do, in order to resolve the issues I explained earlier.

IMO this is not a particularly sensible thing to do. The linking problem is
caused by you using libc, and "inventing" an appropriate entry for the
linker is probably not appropriate at all. You're far better off not linking
with the standard library, but instead finding a source implementation of
the function you want (that you can use subject to licensing restrictions)
that you know is kernel-safe.

MH.