Re: Double or floating point on edk2 ?

[Michael Zimmermann <sigmaepsilon92@gmail.com>]

sry for bringing up this ancient thread but I got a question about this:
shouldn't soft-float be 100% safe because it's a software implementations
and thus never throw exceptions?

Thanks
Michael

On Tue, Dec 8, 2015 at 6:28 PM, Shubha Ramani <shubharamani@yahoo.com>
wrote:

> Thanks for your well-thought out and detailed answer !I guess the safe bet
> is "No". Stay away from floating point on EDK2.
> Shubha Shubha D. Ramanishubharamani@gmail.com
> shubharamani@yahoo.com
>
>
>     On Saturday, December 5, 2015 4:24 PM, Scott Duplichan <
> scott@notabs.org> wrote:
>
>
>  Daryl McDaniel [mailto:edk2-lists@mc2research.org] wrote:
>
> ]Sent: Saturday, December 05, 2015 11:00 AM
> ]To: 'Shubha Ramani' <shubharamani@yahoo.com>; edk2-devel@ml01.01.org
> ]Subject: Re: [edk2] Double or floating point on edk2 ?
> ]
> ]Hello,
> ]
> ]Doing floating point operations within the UEFI environment
> ]is not recommended.  There are many reasons, but the main one
> ]is that floating point exceptions are unlikely to be handled.
>
> I think the need to enable and trap floating point exceptions
> is rare. For most applications, the normal masked response
> works well. Here is Intel's official position:
>
>   "Exception-handling software is often difficult to write,
>     and the masked responses have been tailored to deliver the
>     most reasonable result for each condition. For the majority
>     of applications, masking all exceptions yields satisfactory
>     results with the least programming effort."
>
> ]The default FPU mode (rounding, precision, ...) may also not
> ]be what you would want.
>
> I think the default FPU mode meets the requirements of the C
> programming language. But if not, it could be changed.
>
> ]There is also a chance that one or more of the UEFI functions
> ]may destroy a floating point or vector register that you are using.
>
> Is this really true? I think the compiler will preserve the registers
> when needed for C code. ASM code could certainly destroy floating
> point registers. A problem would occur if SMI or the timer interrupt
> code were to use floating point registers. Could it be possible
> for timer callback code to use floating point and destroy registers
> of the interrupted application?
>
> ]That said, there is nothing that would prevent you from using
> ]floating point types and operations in your Shell application.
> ]If you do, it is your responsibility to ensure that the environment
> ]is properly set up for your needs.  The UEFI specification details
> ]what registers are preserved, or not.
> ]
> ]Using StdLib does not alleviate this responsibility.  The only thing
> ]StdLib does is ensure that the correct rounding, floor, and NAN modes
> ]are set in the FPU in order to conform to the ISO/IEC 9899 Addendum-1
> ](C95) specification.  The sole purpose of StdLib's floating point
> ]support is to facilitate porting existing C applications to the UEFI
> ]environment.
> ]
> ]Unfortunately, using floating point is entirely at your own risk.
>
> The good thing is the problem with unresolved external symbol __dtoui3
> is gone with the current EDK2. This problem used to occur when building
> AppPkg for IA32 using VS2013 or newer. It no longer occurs because of
> "BaseTools: Add /arch:IA32 option in VS2012 and VS2013". Though that
> change was made to prevent the compiler from generating the cmov
> instruction, it also has the side effect of turning off SSE2 math.
>
> Thanks,
> Scott
>
>
> ]Sincerely,
> ]Daryl McDaniel
>
>
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Shubha Ramani
> > Sent: Friday, December 04, 2015 4:39 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] Double or floating point on edk2 ?
> >
> > I know this question has been answered before. Do I need to convert my
> application to a UEFI StdLib applicationto do double or
> > floating point math ? Can't do it in a regular Shell App ?
> > Please illuminate.
> > Thanks,
> > Shubha Shubha D. Ramanishubharamani@gmail.com
> > shubharamani@yahoo.com
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>