Floating point issue

NTDEV
1

Hi,

I’m new here, and hope this is not a stupid question…

Reading the most recent documentation (MS.WDK.v10.6001.080214), I came
across this regarding the use of floating point or MMX in a WDM driver:

…
However, on Itanium-based and x64-based systems, you can use floating point
operations in any IRQL, and the KeSaveFloatingPointState and
KeRestoreFloatingPointState routine are unnecessary
…

What do they mean with x64? Is it every processor with AMD64 or EM64T? If
so, this covers almost every processor available in stores today for
mainstream desktop computers.

Second, does this mean that I can call, for example, sin() function from
inside a ISR? If so, where can I find a valid library with floating-point
math like sin and sqrt?

Thanks

Miguel

2

Miguel Silva wrote:

I’m new here, and hope this is not a stupid question…

Not at all. You can be SURE that we will let you know when you ask a
stupid question. It’s one of the things we excel at.

Reading the most recent documentation (MS.WDK.v10.6001.080214), I came
across this regarding the use of floating point or MMX in a WDM driver:

…
However, on Itanium-based and x64-based systems, you can use floating point
operations in any IRQL, and the KeSaveFloatingPointState and
KeRestoreFloatingPointState routine are unnecessary
…

What do they mean with x64? Is it every processor with AMD64 or EM64T? If
so, this covers almost every processor available in stores today for
mainstream desktop computers.

No, it specifically means a processor that is running a 64-bit version
of Windows. A 64-bit capable processor that is running in 32-bit mode
is indistinguishable from a Pentium, and has the same limitations.

Second, does this mean that I can call, for example, sin() function from
inside a ISR? If so, where can I find a valid library with floating-point
math like sin and sqrt?

libcntpr.lib includes a nearly complete implementation of the C run-time
library for kernel use, including the transcendental functions. It’s
been available for quite a long time. I make no promises as to whether
they work inside an ISR. Intuitively, I can think of no reasons why
they would not, although one might question whether one should be
spending that much time in an ISR.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

> What do they mean with x64?

x64 is x86_64, i.e. AMD64 and Intel 64-bit extensions to x86 (originally developed by AMD). IA64 is Itanium, which is a completely different architecture that is basically different from x86,

Second, does this mean that I can call, for example, sin() function from inside a ISR?

If you find a kernel library that exports it, then, apparently, yes. However, please note that , although you can do irrational things ( for example, causing injuries to yourself, or damaging your property, or running complex scientific calculations in ISR, etc), it does not necessarily mean that you should…

Anton Bassov

4

Hello,

as you can see in wdm.h, KeSaveFloatingPointState() & KeRestoreFloatingPointState() are just STATUS_SUCCESS dummies for the x86-64 & IA64 build environments.

Linking against libcntpr.lib will enable most C math functions, but there are notable exceptions depending on version (w2k, wxp, wnet, wlh) and architectures.

5

x86 has a bit weird handling of FP exceptions. This means, the exception won’t happen immediately, but may be delayed until next FPU instruction. If you happen to have next FPU instruction while you’re running your ISR, you’re screwed. This is why KeSafeFloatingPointState saves your back.
X64 apparently is not as brain damaged.

6

xxxxx@broadcom.com wrote:

x86 has a bit weird handling of FP exceptions. This means, the exception won’t happen immediately, but may be delayed until next FPU instruction. If you happen to have next FPU instruction while you’re running your ISR, you’re screwed. This is why KeSafeFloatingPointState saves your back.

There’s more to it than that. Because it is so expensive to save and
restore the floating point state in the x86, the registers are not saved
during a user/kernel transition (or a kernel thread switch, I forget
which one). If a kernel thread hacks on the floating point registers
without a manual save and restore, chaos ensues.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

>… it is so expensive to save and restore the floating point state in the x86

which automatically implies that moving from FP registers to memory and vice versa is expensive operation it itself. Why someone may want to do it * in ISR* is just beyond me…

Anton Bassov

8

Thank you all for the answers.

I must clarify something, I don´t want anyone to think I’m just another
lunatic trying to go against the rules and destroy the “perfect” harmony of
things!

I’m a R&D Engineer in a Portuguese Institute inside the School of
Engineering of the University of Oporto. I’m trying to determine if XP (and
probably Vista next) is capable of handling a soft real-time application, in
a particular enviornment, to monitor and control machines. I know this is
not the correct architecture but as I said this is intended to be soft
real-time, not hard-real time.

The PC will only work with a GUI communicating with a driver written for a
data acquisition board interrupt capable. There will be no more applications
running, except the ones for system.

The board will generate a int at every 1ms (or more, will just have to see
if we can) and try to implement the following:

  • read analog input ports
  • generate next point (this is where I need float math if possible or
    else I’ll just work with lookup tables and integer math)
  • implement a controller (PID or something similar, again it would be
    nice to have float math)
  • update analog output ports

Doing this in a DPC routine is just not possible. There is no control over
when the routine is executed and then there wouldn’t even be a soft
real-time solution but a “sometime in the next few microseconds it will
happen”-time solution. This considering the dpc will run before the next
int…

As you can see this is NOT going to be distributed in large scale like a
mouse or joystick driver, so I think there is no problem in “bending” the
rules here. Also, this is already implemented in a W98SE enviornment and it
works great at 2ms latency.

Just as a final note I must say that it’s particularly strange that we have
this feature available. In my line of work I came to the conclusion that if
something is particularly not right, the best thing to do is to just not
provide the tools for someone ever consider doing it.

I’m not trying to hurt/kill myself or the computer world, like Anton
implied. I’m just trying to go to the limits of the operating system
capabilities in a special enviornment, like using test dummies in crash
simulations.

Thanks,

Miguel

wrote in message news:xxxxx@ntdev…
> >… it is so expensive to save and restore the floating point state in
> >the x86
>
> which automatically implies that moving from FP registers to memory and
> vice versa is expensive operation it itself. Why someone may want to do it
> * in ISR* is just beyond me…
>
> Anton Bassov
>

9

> I’m trying to determine if XP (and probably Vista next) is capable of handling a soft real-time application,

The answer is negative, because NT is *NOT* a real-time OS and will never become the one.Period. If you have soft real-time requirements., I would say your best bet is Windows CE. Another option is to write your own microkernel that runs Windows as a task. This is what you need if you have *soft* RT requirements. If have have more strict ones, then you need a special-purpose OS that operates some special-purpose hardware , because interrupt latency implied by x86 is too high to meet the demands of true RTOS

There is no control over when the routine is executed and then there wouldn’t even be a soft real-time >solution but a “sometime in the next few microseconds it will happen”-time solution.

Don’t forget that your interrupt will be held pending until all interrupts of higher priority are serviced. Therefore, “sometime in the next few microseconds it will happen”-time solution is the best thing that you can achieve under NT, even if you do things in ISR

Also, this is already implemented in a W98SE enviornment and it works great at 2ms latency.

Please note that 2ms is 2000 microseconds. Therefore, I don’t really understand why you are not happy about “sometime in the next few microseconds it will happen”-time solution while 2000 microseconds latency is perfectly acceptable for you…

I’m just trying to go to the limits of the operating system capabilities in a special enviornment,

If your device interrupts every ms and you do complex floating-point calculations in ISR… then.I am afraid the OS will have very little time to do anything, apart from servicing interrupts that your device raises…

Anton Bassov

10

> The answer is negative, because NT is *NOT* a real-time OS and will never

become the one.Period. If you have soft real-time requirements., I would
say your best bet is Windows CE. Another option is to write your own
microkernel that runs Windows as a task. This is what you need if you have
*soft* RT requirements. If have have more strict ones, then you need a
special-purpose OS that operates some special-purpose hardware , because
interrupt latency implied by x86 is too high to meet the demands of true
RTOS

Yes you are obviously correct and it was not my intention to state
otherwise, I know NT are not RTOS. My intention is to evaluate how a non
RTOS can perform under timed specifications like in soft real-time
applications. If I wanted RT performance I would go for a computer running a
specific RT kernel (freedos or so) and another computer running a monitor
application.

Don’t forget that your interrupt will be held pending until all interrupts
of higher priority are serviced. Therefore, “sometime in the next few
microseconds it will happen”-time solution is the best thing that you can
achieve under NT, even if you do things in ISR

>Also, this is already implemented in a W98SE enviornment and it works
>great at 2ms latency.

Please note that 2ms is 2000 microseconds. Therefore, I don’t really
understand why you are not happy about “sometime in the next few
microseconds it will happen”-time solution while 2000 microseconds
latency is perfectly acceptable for you…

With most recent processors 1 milisecond is perfectly achievable with a few
micoseconds delay for servicing an interrupt. The latency for the dpc is
another story…

> I’m just trying to go to the limits of the operating system capabilities
> in a special enviornment,

If your device interrupts every ms and you do complex floating-point
calculations in ISR… then.I am afraid the OS will have very little
time to do anything, apart from servicing interrupts that your device
raises…

Anton Bassov

This is exactly what I want to evaluate: for a given frequency, how much can
I put inside an ISR, with or without float math, until the computer starts
to sense difficulties to do other jobs. Or for a given load inside an ISR
how high can the frequency be.

In any case this is something I’m going to do. Perhaps I can in a near
future tell you the results of my experience.

Thanks, every opinion is very important to me

Miguel

11

xxxxx@hotmail.com wrote:

> .... it is so expensive to save and restore the floating point state in the x86
which automatically implies that moving from FP registers to memory and vice versa is expensive operation it itself. Why someone may want to do it * in ISR* is just beyond me....

Actually, it just implies that the designers of NT thought that it was
an *unwarranted" use of time for every context switch.

It's *somewhat* expensive. But really not all that expensive. Especially
not on modern hardware. It's only a few dozen instructions (perhaps
unless there's an FP exception pending on x86... that's beyond the scope
of this discussion), but that was a lot when NT was designed and many
machines were CPU bound some of the time. And how many people really
needed FP in the kernel anyway? Having some functions you had to call to
do it was a pretty small burden by comparison.

It's really not any more efficient to save and restore FP state on an
x64 processor (except perhaps for dealing with exceptions). But
processors are so fast these days that you're almost *never* going to be
compute bound, so it doesn't surprise me that MS decided to save the FP
state for you in a context switch on a *known modern* processor... it's
certainly a lot safer.

Anyway, OP, for your purposes just save and restore the floating point
state with the aforementioned functions. Do be careful not to cause any
floating point exceptions, of course, or your machine will blue screen.

Uh... which makes me very nervous about using those math libraries in an
ISR, BTW. That would be the real concern... you don't know what they
might do. They might rely on handling FP exceptions in border conditions
in order to speed up everything else... hard to tell without
disassembling them.

Ray
(If you want to reply to me off list, please remove "spamblock." from my
email address)