Hi,
I'm going to explain this ONCE:
1st: The move was to conserve and reduce space and size of the current structure.
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 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.
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.
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
Use of indices for queries with comparisons based on a function: http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1193619&F=0
System and method for fast and smooth rendering of lit, textured spheres: http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1227443&F=0
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/
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev