AW: LUA_NUMBER -> Integer conversion bug

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

AW: LUA_NUMBER -> Integer conversion bug

Sebastian Rohde

Hi,

MikePall wrote:
> Maybe. Maybe not. Do you use Direct3D/DirectX? If yes, then you
> are just shadowing the problem here and it will come back to
> haunt you elsewhere. Read:

>  http://lua-users.org/lists/lua-l/2005-10/msg00254.html

> It should be noted that turning on D3DCREATE_FPU_PRESERVE
> reportedly has no detectable performance impact on modern CPUs.

I can see your point but I don't think that lua handles this problem
correctly. As soon as lua does "conversion tricks" that assume the
coprocessor to be in a specific state lua has to take care about being in
that state AND recovering the old state afterwards. This is what you expect
from DirectX and what DirectX is does using D3DCREATE_FPU_PRESERVE.

Everything that does an implicit assumption concerning the FPU state (which
I did not find noted in any doc yet?) has to be considered as a bug, imho.

Yours,
Sebastian
Reply | Threaded
Open this post in threaded view
|

Re: LUA_NUMBER -> Integer conversion bug

Mike Pall-3-2
Hi,

Sebastian Rohde wrote:
> I can see your point but I don't think that lua handles this problem
> correctly. As soon as lua does "conversion tricks" that assume the
> coprocessor to be in a specific state lua has to take care about being in
> that state AND recovering the old state afterwards. This is what you expect
> from DirectX and what DirectX is does using D3DCREATE_FPU_PRESERVE.

No. The "standard" FPU state is very well defined by various
documents. The most notable are the x86 ABIs for POSIX and
Windows. The former specifies fpucw = 0x37f, the latter specifies
fpucw = 0x27f. They differ only in the default precision setting
(extended vs. double).

Microsoft choose to deviate from this with DirectX by leaving the
FPU state set to "float" precision. Blame them, not Lua. In fact
D3DCREATE_FPU_PRESERVE really should've been the default setting.
Even back then when it mattered (on a Pentium I or II without GPU
acceleration). If you choose to live dangerously then you should
get the option, but not just by accident.

> Everything that does an implicit assumption concerning the FPU state (which
> I did not find noted in any doc yet?) has to be considered as a bug, imho.

This is not just about "conversion tricks". Every compiler
generates tons of code which relies on the implicit assumptions
from the ABI. Many math functions will produce invalid results if
the precision or the rounding mode is not the default. Changing
the default FPU state is a really bad idea.

Anyway, you would've gotten wrong results even with earlier Lua
versions, except under different circumstances. Try this:

$ lua -e 'local y=987654321; print(y, y+0)'
987654321 987654321

$ lua -l setfpu -e 'local y=987654321; print(y, y+0)'
987654321 987654336

Here "setfpu" is a library which sets the FPU state to float
precision, just like DirectX without D3DCREATE_FPU_PRESERVE. IMHO
finding out about this problem earlier with Lua 5.1 is a bonus.

Bye,
     Mike
Reply | Threaded
Open this post in threaded view
|

Re: LUA_NUMBER -> Integer conversion bug

Achromat
Hi there !

i do the same :-)

make it so :

static void *pid = (void *)"this";  //static ident


  //------ register this pointer as userdata ---------
 lua_pushlightuserdata(m_pState, pid);     //descriptor name
 lua_pushlightuserdata(m_pState, (void*)this);//descriptor data
        lua_settable(m_pState, LUA_REGISTRYINDEX);
 //--------------------------------------------------


//after load init lua regitster an callback
lua_pushcclosure (m_pState, _GetRPixel, 0);lua_setglobal (m_pState,
"GetRPixel");<<--final lua script has new command

//let show the direct callback so

int CLuaCallBacks::_GetRPixel(lua_State *lua)
{
 lua_pushlightuserdata(lua, pid);  //here u get with the ident ur this
poibter to call into ur class
 lua_gettable(lua, LUA_REGISTRYINDEX);
        CLuaScript *pThis = (CLuaScript *)lua_touserdata(lua, -1);

    if(pThis)//GetRpix same as GetPixel(x,y, (DWORD))
    {
  lua_pushnumber(lua, pThis->GetRPix(lua_tonumber(lua, 1),lua_tonumber(lua,
2)));
  return 1;
    }
 return 0;
}





hope u can see what u need ..
greetings
----- Original Message -----
From: "Mike Pall" <[hidden email]>
To: "Lua list" <[hidden email]>
Sent: Monday, March 13, 2006 12:05 PM
Subject: Re: LUA_NUMBER -> Integer conversion bug


> Hi,
>
> Sebastian Rohde wrote:
>> I can see your point but I don't think that lua handles this problem
>> correctly. As soon as lua does "conversion tricks" that assume the
>> coprocessor to be in a specific state lua has to take care about being in
>> that state AND recovering the old state afterwards. This is what you
>> expect
>> from DirectX and what DirectX is does using D3DCREATE_FPU_PRESERVE.
>
> No. The "standard" FPU state is very well defined by various
> documents. The most notable are the x86 ABIs for POSIX and
> Windows. The former specifies fpucw = 0x37f, the latter specifies
> fpucw = 0x27f. They differ only in the default precision setting
> (extended vs. double).
>
> Microsoft choose to deviate from this with DirectX by leaving the
> FPU state set to "float" precision. Blame them, not Lua. In fact
> D3DCREATE_FPU_PRESERVE really should've been the default setting.
> Even back then when it mattered (on a Pentium I or II without GPU
> acceleration). If you choose to live dangerously then you should
> get the option, but not just by accident.
>
>> Everything that does an implicit assumption concerning the FPU state
>> (which
>> I did not find noted in any doc yet?) has to be considered as a bug,
>> imho.
>
> This is not just about "conversion tricks". Every compiler
> generates tons of code which relies on the implicit assumptions
> from the ABI. Many math functions will produce invalid results if
> the precision or the rounding mode is not the default. Changing
> the default FPU state is a really bad idea.
>
> Anyway, you would've gotten wrong results even with earlier Lua
> versions, except under different circumstances. Try this:
>
> $ lua -e 'local y=987654321; print(y, y+0)'
> 987654321 987654321
>
> $ lua -l setfpu -e 'local y=987654321; print(y, y+0)'
> 987654321 987654336
>
> Here "setfpu" is a library which sets the FPU state to float
> precision, just like DirectX without D3DCREATE_FPU_PRESERVE. IMHO
> finding out about this problem earlier with Lua 5.1 is a bonus.
>
> Bye,
>     Mike
>