[ros-dev] [ros-diffs] [jimtabor] 33830: Move xform data from W structure into DcLevel within unions.

Timo Kreuzer timo.kreuzer at web.de
Sat Jun 7 05:49:01 CEST 2008


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 at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>   



More information about the Ros-dev mailing list