7 Jun
2008
7 Jun
'08
3:49 a.m.
James Tabor wrote:
Hi,
I'm going to explain this ONCE:
1st: The move was to conserve and reduce space and size of the current
structure.
There's already a patch from Stefan100, removing it completely ;-)
Don't fear, I'm not going to commit it before next release (sorry Stefan
;-))
Writing a floating point package could be hard to do or just copyleft
one off the net.... Problem is if we do the later it will most likely
not be compatible with M$ SFPP. BTW, M$ did patent their strange and
unusual floating point package. Which means I can not write one! Just
I couldn't see any patent in the below list that covers ms fp emulation
(see below). fp emulation is not patented in general, even if ms way of
storing the floating points would be patented, we could work around it
using a different way, but I doubt that it is patented. If I'm wrong,
please let me know.
writing the storage emulation is almost a problem
too... But due to US
patent law I can just do what I did, to "Talk to the Interface" with
the storage emulation.
I'm going to look into this after the next release. Afaik this is only
needed for x86 (x86_64 as well?), so I'm thinking about a fast asm
implementation. If soeone knows another architecture that needs it, let
me know.
Keeping the current state of ReactOS FP is my first
choice. We use the
speed of the FPU which is part of the main processor and reduce the
size of the source. (Two pluses so far, Speed and Small Size.) The
storage emulation for gdi32 is important for compatibility and with
ReactOS concept of drop in replacement and play.
Using fp emulation instead of fpu in the kernel is not optional. There's
a reaon for that. MS didn't invent FLOATOBJ_Xxx functions for fun...
They are there to provide an alternative to the fpu. Yes, you can use
the fpu, but then you neeed to wrap it in
Ke/EngSave/RestoreFloatingPointSate. Still there's FLOATOBJ and friends
and they must not use the fpu.
If you want to use the fpu, you first need to change the kernel to do
the proper context savings for the fpu state ~ probably messing up
overall performance ~ or stick to the way ms does it: not use the fpu.
Thanks,
my 1EU
References:
Fast floating-point truncation to integer form - US Patent 6535898:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6535898&F=0
This does only apply for use of different rounding models.We don't need
to care about that. It has nothing todo with using one mode of float to
integer conversion or even with floating point emulation.
Use of indices for queries with comparisons based on a
function:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1193619&F=0
Might effect it very slighty, but I'm sure there's a workaround.
System and method for fast and smooth rendering of
lit, textured spheres:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1227443&F=0
Has afaics nothing to do with floating point emulation.
John R. Hauser SoftFloat package :
http://www.jhauser.us/arithmetic/SoftFloat.html
IEEE 754 floating-point test software:
http://www.math.utah.edu/~beebe/software/ieee/
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev