lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


I presume the number2int that fails is the arithmetic version not
the inline assembler. Or do both fail?

DB

On 10/21/05, Mike Pall <mikelu-0510@mike.de> wrote:
> Hi,
>
> Roberto Ierusalimschy wrote:
> > > This will probably be due to something mucking about with global fpu
> > > flags, probably dx I remember having issues with this sort of thing
> > > before.
> >
> > Can you give more details about that problem?
>
> This is a well known issue when mixing DirectX and other
> floating-point code. This affects lots of programs and not
> just Lua. It has been mentioned on the list several times.
>
> Quoting:
>   http://msdn.microsoft.com/archive/en-us/directx9_c_dec_2004/directx/GamesForWindows/TopIssues.asp
>
>  "Direct3D will set the floating-point unit to single-precision,
>   round-to-nearest as part of initialization (unless the
>   D3DCREATE_FPU_PRESERVE flag is used, in which case the FP control
>   word is untouched)."
>
> Summary: This is not a Lua problem. It's DirectX violating the
> x86/x87 ABI which requires the FP control-word to be in a specific
> state. Lua depends on the standard setting in several places.
>
> The new thing in Lua 5.1 is that it's _guaranteed_ to break,
> because the new number2int conversion trick fails. And this one
> is used in lots of places (e.g.: x = t[1]).
>
> With earlier Lua versions it failed only intermittently -- which
> is worse, because you may never find out.
>
> Maybe this fact deserves a special mention in the manual.
>
> Bye,
>      Mike
>