Re: FP arithmetic on Kernel Mode -

NTDEV
1

Why do you state " b) Do your (single) FP operation"? There is no
requirement to limit your FP operations to a single operation. Once you save
the fp state you can perform as many operations as you desire before you
restore the state.

Paul Lever
----- Original Message -----
From: “Miguel Monteiro”
To: “NT Developers Interest List”
Sent: Wednesday, June 20, 2001 3:07 AM
Subject: [ntdev] FP arithmetic on Kernel Mode - Done, thank you. :slight_smile:

> Thank you, Elyas.
> I did searched the newsgroup archives you gently pointed me out. As
> I suspected, this is not a peaceful question. If anyone’s interested,
> here’s what I’ve learned and concluded about the subject:
>
> 1. Floating point operations in kernel-mode doesn’t make great sense.
>
> 2. If sense is not to be called here, you should be aware that FP
> support in KM is very limited.
>
> 3. In fact, there’s no guarantee that NT 4.0 and prior releases support
> FP in KM.
>
> 4. If you’re using Win2K the FP restriction has been lifted: you may
> use FP math in KM. But it’s best to stick with integer math.
>
> 5. If you really, really insist on using FP math then:
>
> a) Save the FP state (KeSaveFloatingPointState)
> b) Do your (single) FP operation
> c) Restore the FP state (KeRestoreFloatingPointState)
>
> 6. Use integer math in KM and pass those silly FP operations up to
> user mode level.
>
> OK, that’s it. I’ll have to resign myself and stick with the last (6)
> “brilliant” bottomline… :)))
>
> Miguel Monteiro
> xxxxx@criticalsoftware.com
> www.criticalsoftware.com
> ------------------------------------------------------------
> “Humour and love are God’s answers
> to Human weaknesses”
> ------------------------------------------------------------
>
> On Monday, June 18, 2001 8:31 PM “Eliyas Yakub” wrote:
>
>
> >Please search the newsgroup archive
> >(http://groups.google.com/groups?hl=en&lr=&safe=off&group=comp.os.ms-wi
> ndows.programmer.nt).
> >This has been discussed several times before.
> >
> >Windows beta2 DDK documentation has new section called “Using Floating
> >Point or MMX in a WDM Driver”. Read that for more info.
> >
> >-Eliyas
>
> —Original Message—
> On Friday, June 15, 2001 11:32 AM I (Miguel Monteiro) wrote:
>
> >Hi,
> >Using FP arithmetic on KM seems a hedious task. :frowning:
> >Strange as it might seem, suppose such task is needed on a km driver.
> >I could:
> >
> >1. Use KeSaveFloatingPointState to save the FP context in a resident
> >(e.g. in the device extension) KFLOATING_SAVE variable;
> >2. Perform the FP operation (e.g. a DOUBLE division);
> >3. Restore the FP context, using KeRestoreFloatingPointState.
> >
> >This scheme works fine for a single operation (A), but what if I need
> to
> >perform a sequence of FP operations:
> >
> >save(A), restore(A), save(B), restore(B) = Ok
> >save(A), save(B), save(C) … restore(C), restore(B), restore(A) = NOT
> >Ok… :frowning:
> >
> >(When dividing, one possible solution would be to use integer
> arithmetic
> >instead, “expanding” the divident (SHL), perform the division and then
> >“shrink” the result (SHR) again. But I’m not sure if the results are
> reliable…)
> >
> >Does anyone know how the “community” has been handling/solving the
> >FP problem on KM drivers? Any tips/points/links are mostly appreciated.
> >
> >Thank you,
> >
> >Miguel Monteiro
> >xxxxx@criticalsoftware.com
> >www.criticalsoftware.com
> >------------------------------------------------------------
> >“Humour and love are God’s answers
> >to Human weaknesses”
> ------------------------------------------------------------
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@home.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

On Thursday, June 21, 2001 12:56 AM “Paul Lever” wrote:

Why do you state " b) Do your (single) FP operation"? There is no
requirement to limit your FP operations to a single operation. Once you
save
the fp state you can perform as many operations as you desire before
you
restore the state.

Paul Lever

I believe you, Paul. And I really expected that behaviour. But
unfortunately,
I had to deal with 3 sequential operations (mostly evolving divisions
with
double type variables) and the kernel behaviour seemed a bit picky here:
once in a while, the driver would refuse to load at all and a pop-up
dialog
box with a “system error - function code not found in dll” (something
like
that) - kept appearing… even BEFORE those computations were actually
performed (it seems to me that the Service Control Manager implements
some kind of mechanism to provide a way of “knowing” that a given
code has “embedded” FP ops in it, and it will simply refuse to cope);
the
only way to circumvent this weird behaviour was, in fact, to use three
“nested” saveFP/restoreFP pairs of operations (one for each FP
operation). I know it sounds silly, but it didn’t seem to work otherwise
(e.g. like the way you said and that it was, of course, the way I
initially
expected the o.s. to behave). Other not-that-strange gizmo was
converting an unsigned 64-bit value (unsigned __int64) to double (e.g.
casting): it’s not supported - that makes sense. What does NOT make
that much sense is not to support a cast from signed 64-bit value
(__int64) to double: I would expect the compiler would give some
kind of warning at most, but instead it happilly compiles that stuff.
That
sounds great, until you get real and found that silly system error
dialog
box popping around again… Anyway, I already cleared up things and
passed up those silly FP operations up to user level. But one thing I’m
sure of: FP in KM is a bitch - use integer arithmetic whenever possible
(meaning: “always use integer arithmetic, unless you’re really stuck and
you need to code a graphics driver to use OpenGL-like stuff, etc. but
then you probably will start listening Alberto and use C++ to code your
driver, as the overhead to deal with FP ops will be significant…”).

(Btw, thank you Eliyas for helping me out with this one)

Miguel Monteiro
xxxxx@criticalsoftware.com
www.criticalsoftware.com

“Humour and love are God’s answers
to Human weaknesses”

----- Original Message -----
From: “Miguel Monteiro”
To: “NT Developers Interest List”
Sent: Wednesday, June 20, 2001 3:07 AM
Subject: [ntdev] FP arithmetic on Kernel Mode - Done, thank you. :slight_smile:

> Thank you, Elyas.
> I did searched the newsgroup archives you gently pointed me out. As
> I suspected, this is not a peaceful question. If anyone’s interested,
> here’s what I’ve learned and concluded about the subject:
>
> 1. Floating point operations in kernel-mode doesn’t make great sense.
>
> 2. If sense is not to be called here, you should be aware that FP
> support in KM is very limited.
>
> 3. In fact, there’s no guarantee that NT 4.0 and prior releases
support
> FP in KM.
>
> 4. If you’re using Win2K the FP restriction has been lifted: you may
> use FP math in KM. But it’s best to stick with integer math.
>
> 5. If you really, really insist on using FP math then:
>
> a) Save the FP state (KeSaveFloatingPointState)
> b) Do your (single) FP operation
> c) Restore the FP state (KeRestoreFloatingPointState)
>
> 6. Use integer math in KM and pass those silly FP operations up to
> user mode level.
>
> OK, that’s it. I’ll have to resign myself and stick with the last (6)
> “brilliant” bottomline… :)))
>
> Miguel Monteiro
> xxxxx@criticalsoftware.com
> www.criticalsoftware.com
> ------------------------------------------------------------
> “Humour and love are God’s answers
> to Human weaknesses”
> ------------------------------------------------------------
>
> On Monday, June 18, 2001 8:31 PM “Eliyas Yakub” wrote:
>
> >Please search the newsgroup archive
>
>(http://groups.google.com/groups?hl=en&lr=&safe=off&group=comp.os.ms-wi
> ndows.programmer.nt).
> >This has been discussed several times before.
> >
> >Windows beta2 DDK documentation has new section called “Using
Floating
> >Point or MMX in a WDM Driver”. Read that for more info.
> >
> >-Eliyas
>
> —Original Message—
> On Friday, June 15, 2001 11:32 AM I (Miguel Monteiro) wrote:
>
> >Hi,
> >Using FP arithmetic on KM seems a hedious task. :frowning:
> >Strange as it might seem, suppose such task is needed on a km driver.
> >I could:
> >
> >1. Use KeSaveFloatingPointState to save the FP context in a resident
> >(e.g. in the device extension) KFLOATING_SAVE variable;
> >2. Perform the FP operation (e.g. a DOUBLE division);
> >3. Restore the FP context, using KeRestoreFloatingPointState.
> >
> >This scheme works fine for a single operation (A), but what if I need
> to
> >perform a sequence of FP operations:
> >
> >save(A), restore(A), save(B), restore(B) = Ok
> >save(A), save(B), save(C) … restore(C), restore(B), restore(A) =
NOT
> >Ok… :frowning:
> >
> >(When dividing, one possible solution would be to use integer
> arithmetic
> >instead, “expanding” the divident (SHL), perform the division and
then
> >“shrink” the result (SHR) again. But I’m not sure if the results are
> reliable…)
> >
> >Does anyone know how the “community” has been handling/solving the
> >FP problem on KM drivers? Any tips/points/links are mostly
appreciated.
> >
> >Thank you,
> >
> >Miguel Monteiro
> >xxxxx@criticalsoftware.com
> >www.criticalsoftware.com
> >------------------------------------------------------------
> >“Humour and love are God’s answers
> >to Human weaknesses”
> ------------------------------------------------------------

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

It’s been almost two years since I last touched that code, so I don’t really
remember anymore, and I don’t have access to it now - but we had a healthy
amount of FP in our Ring 0 OpenGL ICD, and we never bumped into any problems
originated from our use of FP in kernel mode. I’m not going to be able to
give you the details of what we saved and restored, but I don’t remember
making any special provisions. And this was C code, not C++. But the ICD
went through a whole lot of synchronization with the rest of Windows as a
matter of fact, so I don’t know where we avoided the FP issue. But now, one
thing is certain, we didn’t call any Windows entry point.

About casts, we found that casting made the compiler generate calls to
library routines which were rather slow. So, we replaced every cast with
inline assembler, and we paid particular attention to correctly pipelining
the FPU. Once our OpenGL architect got a massive improvement in speed by
correctly pipelining the divide instruction in the perspective divide stage
of the graphics pipeline!

And yes, if I had to do it all over again, I’d do it in C++. :wink:

Alberto.

-----Original Message-----
From: Miguel Monteiro [mailto:xxxxx@criticalsoftware.com]
Sent: Thursday, June 21, 2001 3:15 AM
To: NT Developers Interest List
Subject: [ntdev] Re: FP arithmetic on Kernel Mode -

Anyway, I already cleared up things and
passed up those silly FP operations up to user level. But one thing I’m
sure of: FP in KM is a bitch - use integer arithmetic whenever possible
(meaning: “always use integer arithmetic, unless you’re really stuck and
you need to code a graphics driver to use OpenGL-like stuff, etc. but
then you probably will start listening Alberto and use C++ to code your
driver, as the overhead to deal with FP ops will be significant…”).

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com