Lua on the PlayStation2

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

Lua on the PlayStation2

Chris Chapman
Just curious if anyone else has had issues trying to use Lua straight out of
the box on the PS2? We've been using it for a while, but in a fairly limited
way. After redirecting the memory managers to our own version, and giving it
a 256KB heap to play in everything seemed to work okay. However after
loading up a bunch more scripts and using it in a more active way, I'm now
encountering problems with garbage collection. 

What seems to be happening is that the 64-bit unsigned integers in the lua
state (->GCthreshold and ->nblocks) are being corrupted, because as far as I
can see the compilers are generating 32-bit arithmetic instructions for the
garbage collection/ string table resizing routines. They didn't show up
before because we never actually had an opportunity to shrink the size of
the string table before.

I realise this is probably best suited to newsgroups for PS2 compilers, so
I'll be posting it there as well; however I'd be interested to hear from
other developers using Lua in a PS2 environment - what did you have to tweak
to get Lua a) working and b) fast?

When we ran our game through the Performance Analyser, Lua showed up as the
worst single culprit for performance, and a lot of that was due to double
precision operations. Even after defining LUA_NUM_TYPE to be float instead
of double, there are still many functions both in the API and internally
which expect double precision arguments. Does anyone know what the
implications of a global search and replace for float to double would be?
How many of the 64 bit values (long is 64 bit on a PlayStation2) used
throughout the library are actually required to be 64-bit? Especially given
that the VM is expected to be running in a low-memory environment.

Thanks
ChrisC


Reply | Threaded
Open this post in threaded view
|

RE: Lua on the PlayStation2

Dave Owens
I didn't even get that far.. See post from last week.

As for the number type, it would be nice if we could have one place where we
could change this to whatever we required. I did get this side working (PC)
but I really loathed having to change the Lua code.


-----Original Message-----
From: Chris Chapman [[hidden email]] 
Sent: 06 October 2003 13:45
To: [hidden email]
Subject: Lua on the PlayStation2


Just curious if anyone else has had issues trying to use Lua straight out of
the box on the PS2? We've been using it for a while, but in a fairly limited
way. After redirecting the memory managers to our own version, and giving it
a 256KB heap to play in everything seemed to work okay. However after
loading up a bunch more scripts and using it in a more active way, I'm now
encountering problems with garbage collection. 

What seems to be happening is that the 64-bit unsigned integers in the lua
state (->GCthreshold and ->nblocks) are being corrupted, because as far as I
can see the compilers are generating 32-bit arithmetic instructions for the
garbage collection/ string table resizing routines. They didn't show up
before because we never actually had an opportunity to shrink the size of
the string table before.

I realise this is probably best suited to newsgroups for PS2 compilers, so
I'll be posting it there as well; however I'd be interested to hear from
other developers using Lua in a PS2 environment - what did you have to tweak
to get Lua a) working and b) fast?

When we ran our game through the Performance Analyser, Lua showed up as the
worst single culprit for performance, and a lot of that was due to double
precision operations. Even after defining LUA_NUM_TYPE to be float instead
of double, there are still many functions both in the API and internally
which expect double precision arguments. Does anyone know what the
implications of a global search and replace for float to double would be?
How many of the 64 bit values (long is 64 bit on a PlayStation2) used
throughout the library are actually required to be 64-bit? Especially given
that the VM is expected to be running in a low-memory environment.

Thanks
ChrisC

Reply | Threaded
Open this post in threaded view
|

Re: Lua on the PlayStation2

Luiz Henrique de Figueiredo
In reply to this post by Chris Chapman
>What seems to be happening is that the 64-bit unsigned integers in the lua
>state (->GCthreshold and ->nblocks) are being corrupted, because as far as I
>can see the compilers are generating 32-bit arithmetic instructions for the
>garbage collection/ string table resizing routines.

I'm not sure where the problem lies or whether it's the compiler's fault, but
if something can be done in the source code to avoid this, we'd like to hear
about it.

We definitely want to see Lua running on the PS2 as smoothly as possible.
Lua on the PS2 has been mentioned before in this list. I think it ran ok.

>When we ran our game through the Performance Analyser, Lua showed up as the
>worst single culprit for performance, and a lot of that was due to double
>precision operations. Even after defining LUA_NUM_TYPE to be float instead
>of double, there are still many functions both in the API and internally
>which expect double precision arguments.

That's odd. There's no mention of double in the code. Perhaps you mean the
use of strtod in lua_str2number and sprintf in lua_number2str. These can be
redefined if necessary.

>Does anyone know what the
>implications of a global search and replace for float to double would be?

Like I said, there are no explict doubles. (What version of Lua are you using?)

>How many of the 64 bit values (long is 64 bit on a PlayStation2) used
>throughout the library are actually required to be 64-bit?

None. See lu_hash and lu_mem in llimits.h.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: Lua on the PlayStation2

Chris Chapman
In reply to this post by Chris Chapman
Sorry, I thought immediately after I sent it that I should have stated
version. We are using lua-4.0.1 which has double in a few places. On
browsing over the 5.0 code it seems they have been fixed. :)

We are hoping to upgrade to 5.0 as soon as possible, but when I tried it
last time there was an obscure crash and I couldn't easily track it in the
limited time available. Would I be right to hazard a guess that 5.0 is a bit
more PS2 friendly that 4.0.1 then? If so I will prioritise upgrading over
tracking this obscure GC/64-bit operation bug.

-----Original Message-----
From: Luiz Henrique de Figueiredo [[hidden email]]
Sent: 06 October 2003 13:56
To: [hidden email]
Subject: Re: Lua on the PlayStation2


>What seems to be happening is that the 64-bit unsigned integers in the lua
>state (->GCthreshold and ->nblocks) are being corrupted, because as far as
I
>can see the compilers are generating 32-bit arithmetic instructions for the
>garbage collection/ string table resizing routines.

I'm not sure where the problem lies or whether it's the compiler's fault,
but
if something can be done in the source code to avoid this, we'd like to hear
about it.

We definitely want to see Lua running on the PS2 as smoothly as possible.
Lua on the PS2 has been mentioned before in this list. I think it ran ok.

>When we ran our game through the Performance Analyser, Lua showed up as the
>worst single culprit for performance, and a lot of that was due to double
>precision operations. Even after defining LUA_NUM_TYPE to be float instead
>of double, there are still many functions both in the API and internally
>which expect double precision arguments.

That's odd. There's no mention of double in the code. Perhaps you mean the
use of strtod in lua_str2number and sprintf in lua_number2str. These can be
redefined if necessary.

>Does anyone know what the
>implications of a global search and replace for float to double would be?

Like I said, there are no explict doubles. (What version of Lua are you
using?)

>How many of the 64 bit values (long is 64 bit on a PlayStation2) used
>throughout the library are actually required to be 64-bit?

None. See lu_hash and lu_mem in llimits.h.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: Lua on the PlayStation2

Luiz Henrique de Figueiredo
In reply to this post by Chris Chapman
>Would I be right to hazard a guess that 5.0 is a bit
>more PS2 friendly that 4.0.1 then?

I'd say so, because we try to make each version of Lua more friendly to
more platforms, based on the reports from users who have tried Lua on those
platforms, but I'm not familiar with nor have access to the PS2.

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua on the PlayStation2

Jeff
In reply to this post by Chris Chapman
Hi Chris, I haven't got any tips for you, but if you get other feedback from
anywhere other than this Lua list, please post it! I'm looking into using
Lua in a similar environment (PS2, XBox, PC) and would be very interested to
hear what you find out.

(The double thing was the first one I noticed, and like you I'm not sure of
the implications of changing it - mainly cos I haven't yet checked!)

Cheers,


Jeff.

----- Original Message ----- 
From: "Chris Chapman" <[hidden email]>
To: <[hidden email]>
Sent: Monday, October 06, 2003 1:45 PM
Subject: Lua on the PlayStation2


> I realise this is probably best suited to newsgroups for PS2 compilers, so
> I'll be posting it there as well; however I'd be interested to hear from
> other developers using Lua in a PS2 environment - what did you have to
tweak
> to get Lua a) working and b) fast?
>
> When we ran our game through the Performance Analyser, Lua showed up as
the
> worst single culprit for performance..........


Reply | Threaded
Open this post in threaded view
|

Re: Lua on the PlayStation2

John Belmonte-2
In reply to this post by Luiz Henrique de Figueiredo
lhf wrote:
Would I be right to hazard a guess that 5.0 is a bit
more PS2 friendly that 4.0.1 then?

I'd say so, because we try to make each version of Lua more friendly to
more platforms, based on the reports from users who have tried Lua on those
platforms, but I'm not familiar with nor have access to the PS2.

Does 5.0 happen to be more dependent on longjump and friends? My oracle tells me that the longjump implementation on the PS2 is bad news.

-John


--
http:// if   le.o  /


Reply | Threaded
Open this post in threaded view
|

Re: Lua on the PlayStation2

Luiz Henrique de Figueiredo
In reply to this post by Chris Chapman
>Does 5.0 happen to be more dependent on longjump and friends?

No more so than in Lua 4.0.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: Lua on the PlayStation2

Chris Chapman
In reply to this post by Chris Chapman
It was dodgy for a little while (only the SN systems implementation, and
only for a month or two). Luckily a day or two after I started to integrate
Lua and came across the setjmp problem (badly sized longjmp structure which
caused a stack trash) someone else also noticed it on the PS2 development
boards, and the problem was promptly fixed. It all boiled down to an old gcc
header which had snuck into the source tree, and which wasn't compatible
with the PS2 architecture (wrong number/size of registers).

I came across an issue while attempting the upgrade to Lua 5.0 that error
handling would die horribly on any kind of error, which I tracked to the
fact that it seems that protected mode calls to Lua were no longer the
default. In 4.0.1, most execution of code seems to go through
luaD_runprotected, which surrounds the code with longjmp protection. In 5.0,
this is no longer the case, unless you use lua_pcall in preference to
lua_call. Would that be an accurate description of the changes?

Anyway, using lua_call and encountering a parse or execution error would
result in a longjmp to an undefined address. That snagged me for a while
until I swapped to using lua_pcall everywhere.

-----Original Message-----
From: John Belmonte [[hidden email]]
Sent: 06 October 2003 16:41
To: Lua list
Subject: Re: Lua on the PlayStation2


lhf wrote:
>>Would I be right to hazard a guess that 5.0 is a bit
>>more PS2 friendly that 4.0.1 then?
> 
> I'd say so, because we try to make each version of Lua more friendly to
> more platforms, based on the reports from users who have tried Lua on
those
> platforms, but I'm not familiar with nor have access to the PS2.

Does 5.0 happen to be more dependent on longjump and friends?  My oracle 
tells me that the longjump implementation on the PS2 is bad news.

-John


-- 
http:// if   le.o  /

Reply | Threaded
Open this post in threaded view
|

RE: Lua on the PlayStation2

Nick Trout
In reply to this post by Chris Chapman




> From: Chris Chapman 
> Sent: Monday, October 06, 2003 6:08 AM
> To: 'Lua list'
> Subject: RE: Lua on the PlayStation2
> 
> Sorry, I thought immediately after I sent it that I should have stated
> version. We are using lua-4.0.1 which has double in a few places. On
> browsing over the 5.0 code it seems they have been fixed. :)
> 
> We are hoping to upgrade to 5.0 as soon as possible, but when I tried
it
> last time there was an obscure crash and I couldn't easily track it in
the
> limited time available. Would I be right to hazard a guess that 5.0 is
a
> bit
> more PS2 friendly that 4.0.1 then? If so I will prioritise upgrading
over
> tracking this obscure GC/64-bit operation bug.


You should probably remove all traces of 64 bit-ness on PS2. This will
save memory and possibly make it run faster. In Lua 5.0 I think you just
need to define LUA_NUMBER as float in your compiler environment, as you
know PS2 doesn't do hardware doubles. long is 64 bit on PS2 so change
all instances of this to int. Go into llimits.h and change all
instances.

Nick


Reply | Threaded
Open this post in threaded view
|

Re: Lua on the PlayStation2

Leigh McRae
In reply to this post by Chris Chapman
  I am using lua 4 and I tried to switch the doubles to floats but I had
some problems.  I have a class called Handle that is really just a 32bit
number that uses 16bits as an id and 16bits for instance verification.
These couldn't be passed around and compared like pointers since two handles
can be the same but be in different memory locations.  So started passing
them as numbers.  When I switched Lua to use floats instead of doubles, it
broke.  The handles would be casted to a float and it would loose its real
value.

  I decided to leave the doubles in for now and address the problem later
:(  I wonder if Lua 5.0 will be the same.  Does Lua 5.0 cast all its numbers
two and from floats?

Leigh McRae
Lead Programmer
Rockstar Games Toronto
www.rockstargames.com


----- Original Message ----- 
From: "Chris Chapman" <[hidden email]>
To: <[hidden email]>
Sent: Monday, October 06, 2003 8:45 AM
Subject: Lua on the PlayStation2


> Just curious if anyone else has had issues trying to use Lua straight out
of
> the box on the PS2? We've been using it for a while, but in a fairly
limited
> way. After redirecting the memory managers to our own version, and giving
it
> a 256KB heap to play in everything seemed to work okay. However after
> loading up a bunch more scripts and using it in a more active way, I'm now
> encountering problems with garbage collection.
>
> What seems to be happening is that the 64-bit unsigned integers in the lua
> state (->GCthreshold and ->nblocks) are being corrupted, because as far as
I
> can see the compilers are generating 32-bit arithmetic instructions for
the
> garbage collection/ string table resizing routines. They didn't show up
> before because we never actually had an opportunity to shrink the size of
> the string table before.
>
> I realise this is probably best suited to newsgroups for PS2 compilers, so
> I'll be posting it there as well; however I'd be interested to hear from
> other developers using Lua in a PS2 environment - what did you have to
tweak
> to get Lua a) working and b) fast?
>
> When we ran our game through the Performance Analyser, Lua showed up as
the
> worst single culprit for performance, and a lot of that was due to double
> precision operations. Even after defining LUA_NUM_TYPE to be float instead
> of double, there are still many functions both in the API and internally
> which expect double precision arguments. Does anyone know what the
> implications of a global search and replace for float to double would be?
> How many of the 64 bit values (long is 64 bit on a PlayStation2) used
> throughout the library are actually required to be 64-bit? Especially
given
> that the VM is expected to be running in a low-memory environment.
>
> Thanks
> ChrisC
>
>


Reply | Threaded
Open this post in threaded view
|

RE: Lua on the PlayStation2

Chris Chapman
In reply to this post by Chris Chapman
Well, I went the whole hog and upgraded to Lua 5.0 and then shifted the
64-bit numbers in the code to 32. FYI, 5.0 worked without any real
modifications (the garbage collection bug I described before did not
reappear straight away - although I did not conclusively test. The 64->32
bit transition wasn't as simple as it could possibly be - there are still
several occurences of long and unsigned long in the code-base. Might I
suggest a typedef so that is localised to a single place? Several of the
occurrences mentioned '32-bit or more', suggesting that a single set of
typedefs for INT32, UINT32, etc. might be appropriate (obviously with the
names munged to avoid conflicts with the Win32 typedefs with the same name).

The only occurrence of double was in the L_Umaxalign definition, which I
changed to be:
	typedef union { float u; void *s; int l; } L_Umaxalign;
instead of
	typedef union { double u; void *s; long l; } L_Umaxalign;

After that, all seems peachy. There appears to be some different behaviour
related to lua_ref, but it may just be reporting dodgy scripts that
previously slipped under the radar.

Only reply on the PS2 dev newsgroups is currently - 'swap all 64 bit types
to 32 bit', which although it solves the problem, doesn't really address the
compiler issue. I will post again if there is anything more explicit to fix
the compilation under GNU.

-----Original Message-----
From: Nick Trout [[hidden email]]
Sent: 06 October 2003 18:55
To: Lua list
Subject: RE: Lua on the PlayStation2







> From: Chris Chapman 
> Sent: Monday, October 06, 2003 6:08 AM
> To: 'Lua list'
> Subject: RE: Lua on the PlayStation2
> 
> Sorry, I thought immediately after I sent it that I should have stated
> version. We are using lua-4.0.1 which has double in a few places. On
> browsing over the 5.0 code it seems they have been fixed. :)
> 
> We are hoping to upgrade to 5.0 as soon as possible, but when I tried
it
> last time there was an obscure crash and I couldn't easily track it in
the
> limited time available. Would I be right to hazard a guess that 5.0 is
a
> bit
> more PS2 friendly that 4.0.1 then? If so I will prioritise upgrading
over
> tracking this obscure GC/64-bit operation bug.


You should probably remove all traces of 64 bit-ness on PS2. This will
save memory and possibly make it run faster. In Lua 5.0 I think you just
need to define LUA_NUMBER as float in your compiler environment, as you
know PS2 doesn't do hardware doubles. long is 64 bit on PS2 so change
all instances of this to int. Go into llimits.h and change all
instances.

Nick

Reply | Threaded
Open this post in threaded view
|

RE: Lua on the PlayStation2

Chris Chapman
In reply to this post by Chris Chapman
Ergh. Would you not be better off treating them as light userdata? You can
compare void* values and they won't go through any nasty floating point
conversions which might bring you problems. That's on the C side at least, I
don't know how you might perform Lua operations (comparison, deconstruction
into ID/verification elements) on them; although I don't know how you are
doing that now if you are passing them round as floating point numbers...

-----Original Message-----
From: Leigh McRae [[hidden email]]
Sent: 07 October 2003 17:19
To: Lua list
Subject: Re: Lua on the PlayStation2


  I am using lua 4 and I tried to switch the doubles to floats but I had
some problems.  I have a class called Handle that is really just a 32bit
number that uses 16bits as an id and 16bits for instance verification.
These couldn't be passed around and compared like pointers since two handles
can be the same but be in different memory locations.  So started passing
them as numbers.  When I switched Lua to use floats instead of doubles, it
broke.  The handles would be casted to a float and it would loose its real
value.

  I decided to leave the doubles in for now and address the problem later
:(  I wonder if Lua 5.0 will be the same.  Does Lua 5.0 cast all its numbers
two and from floats?

Leigh McRae
Lead Programmer
Rockstar Games Toronto
www.rockstargames.com


----- Original Message ----- 
From: "Chris Chapman" <[hidden email]>
To: <[hidden email]>
Sent: Monday, October 06, 2003 8:45 AM
Subject: Lua on the PlayStation2


> Just curious if anyone else has had issues trying to use Lua straight out
of
> the box on the PS2? We've been using it for a while, but in a fairly
limited
> way. After redirecting the memory managers to our own version, and giving
it
> a 256KB heap to play in everything seemed to work okay. However after
> loading up a bunch more scripts and using it in a more active way, I'm now
> encountering problems with garbage collection.
>
> What seems to be happening is that the 64-bit unsigned integers in the lua
> state (->GCthreshold and ->nblocks) are being corrupted, because as far as
I
> can see the compilers are generating 32-bit arithmetic instructions for
the
> garbage collection/ string table resizing routines. They didn't show up
> before because we never actually had an opportunity to shrink the size of
> the string table before.
>
> I realise this is probably best suited to newsgroups for PS2 compilers, so
> I'll be posting it there as well; however I'd be interested to hear from
> other developers using Lua in a PS2 environment - what did you have to
tweak
> to get Lua a) working and b) fast?
>
> When we ran our game through the Performance Analyser, Lua showed up as
the
> worst single culprit for performance, and a lot of that was due to double
> precision operations. Even after defining LUA_NUM_TYPE to be float instead
> of double, there are still many functions both in the API and internally
> which expect double precision arguments. Does anyone know what the
> implications of a global search and replace for float to double would be?
> How many of the 64 bit values (long is 64 bit on a PlayStation2) used
> throughout the library are actually required to be 64-bit? Especially
given
> that the VM is expected to be running in a low-memory environment.
>
> Thanks
> ChrisC
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Lua on the PlayStation2

Virgil Smith
In reply to this post by Leigh McRae
If you have a 32 bit "handle", I'd suggest using a Light User Data rather
than a number, that should work around the float issue and be a little less
misleading in the type information.

If you wish the compare to be handled properly (in a semantic fashion
indicating that 2 handles reference the same object) then use a full user
data and set an "eq" metamethod.



-----Original Message-----
From: [hidden email]
[[hidden email] Behalf Of Leigh McRae
Sent: Tuesday, October 07, 2003 11:19 AM
To: Lua list
Subject: Re: Lua on the PlayStation2


  I am using lua 4 and I tried to switch the doubles to floats but I had
some problems.  I have a class called Handle that is really just a 32bit
number that uses 16bits as an id and 16bits for instance verification.
These couldn't be passed around and compared like pointers since two handles
can be the same but be in different memory locations.  So started passing
them as numbers.  When I switched Lua to use floats instead of doubles, it
broke.  The handles would be casted to a float and it would loose its real
value.

  I decided to leave the doubles in for now and address the problem later
:(  I wonder if Lua 5.0 will be the same.  Does Lua 5.0 cast all its numbers
two and from floats?

Leigh McRae
Lead Programmer
Rockstar Games Toronto
www.rockstargames.com


----- Original Message -----
From: "Chris Chapman" <[hidden email]>
To: <[hidden email]>
Sent: Monday, October 06, 2003 8:45 AM
Subject: Lua on the PlayStation2


> Just curious if anyone else has had issues trying to use Lua straight out
of
> the box on the PS2? We've been using it for a while, but in a fairly
limited
> way. After redirecting the memory managers to our own version, and giving
it
> a 256KB heap to play in everything seemed to work okay. However after
> loading up a bunch more scripts and using it in a more active way, I'm now
> encountering problems with garbage collection.
>
> What seems to be happening is that the 64-bit unsigned integers in the lua
> state (->GCthreshold and ->nblocks) are being corrupted, because as far as
I
> can see the compilers are generating 32-bit arithmetic instructions for
the
> garbage collection/ string table resizing routines. They didn't show up
> before because we never actually had an opportunity to shrink the size of
> the string table before.
>
> I realise this is probably best suited to newsgroups for PS2 compilers, so
> I'll be posting it there as well; however I'd be interested to hear from
> other developers using Lua in a PS2 environment - what did you have to
tweak
> to get Lua a) working and b) fast?
>
> When we ran our game through the Performance Analyser, Lua showed up as
the
> worst single culprit for performance, and a lot of that was due to double
> precision operations. Even after defining LUA_NUM_TYPE to be float instead
> of double, there are still many functions both in the API and internally
> which expect double precision arguments. Does anyone know what the
> implications of a global search and replace for float to double would be?
> How many of the 64 bit values (long is 64 bit on a PlayStation2) used
> throughout the library are actually required to be 64-bit? Especially
given
> that the VM is expected to be running in a low-memory environment.
>
> Thanks
> ChrisC
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Lua on the PlayStation2

Leigh McRae
  I didn't see a eq metamethod for Lua 4.  I will check again, if so I will
use this.  I did write a function called AreEqual() for the scripters but I
felt dirty and it was really prone to error.

  Casting the value of a handle to a void pointer would work, as a previous
post suggested.  Looking back on the problem, I am thinking that it was more
of a tolua issue I was having.  I ended up changing tolua to treat Handles
as numbers when maybe what I really wanted was void pointers.  I will have
to look at it again, thanks for the ideas.

Leigh McRae
Lead Programmer
Rockstar Games Toronto
www.rockstargames.com


----- Original Message ----- 
From: "Virgil Smith" <[hidden email]>
To: "'Lua list'" <[hidden email]>
Sent: Tuesday, October 07, 2003 1:32 PM
Subject: RE: Lua on the PlayStation2


> If you have a 32 bit "handle", I'd suggest using a Light User Data rather
> than a number, that should work around the float issue and be a little
less
> misleading in the type information.
>
> If you wish the compare to be handled properly (in a semantic fashion
> indicating that 2 handles reference the same object) then use a full user
> data and set an "eq" metamethod.
>
>
>
> -----Original Message-----
> From: [hidden email]
> [[hidden email] Behalf Of Leigh McRae
> Sent: Tuesday, October 07, 2003 11:19 AM
> To: Lua list
> Subject: Re: Lua on the PlayStation2
>
>
>   I am using lua 4 and I tried to switch the doubles to floats but I had
> some problems.  I have a class called Handle that is really just a 32bit
> number that uses 16bits as an id and 16bits for instance verification.
> These couldn't be passed around and compared like pointers since two
handles
> can be the same but be in different memory locations.  So started passing
> them as numbers.  When I switched Lua to use floats instead of doubles, it
> broke.  The handles would be casted to a float and it would loose its real
> value.
>
>   I decided to leave the doubles in for now and address the problem later
> :(  I wonder if Lua 5.0 will be the same.  Does Lua 5.0 cast all its
numbers
> two and from floats?
>
> Leigh McRae
> Lead Programmer
> Rockstar Games Toronto
> www.rockstargames.com
>
>
> ----- Original Message -----
> From: "Chris Chapman" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, October 06, 2003 8:45 AM
> Subject: Lua on the PlayStation2
>
>
> > Just curious if anyone else has had issues trying to use Lua straight
out
> of
> > the box on the PS2? We've been using it for a while, but in a fairly
> limited
> > way. After redirecting the memory managers to our own version, and
giving
> it
> > a 256KB heap to play in everything seemed to work okay. However after
> > loading up a bunch more scripts and using it in a more active way, I'm
now
> > encountering problems with garbage collection.
> >
> > What seems to be happening is that the 64-bit unsigned integers in the
lua
> > state (->GCthreshold and ->nblocks) are being corrupted, because as far
as
> I
> > can see the compilers are generating 32-bit arithmetic instructions for
> the
> > garbage collection/ string table resizing routines. They didn't show up
> > before because we never actually had an opportunity to shrink the size
of
> > the string table before.
> >
> > I realise this is probably best suited to newsgroups for PS2 compilers,
so
> > I'll be posting it there as well; however I'd be interested to hear from
> > other developers using Lua in a PS2 environment - what did you have to
> tweak
> > to get Lua a) working and b) fast?
> >
> > When we ran our game through the Performance Analyser, Lua showed up as
> the
> > worst single culprit for performance, and a lot of that was due to
double
> > precision operations. Even after defining LUA_NUM_TYPE to be float
instead
> > of double, there are still many functions both in the API and internally
> > which expect double precision arguments. Does anyone know what the
> > implications of a global search and replace for float to double would
be?
> > How many of the 64 bit values (long is 64 bit on a PlayStation2) used
> > throughout the library are actually required to be 64-bit? Especially
> given
> > that the VM is expected to be running in a low-memory environment.
> >
> > Thanks
> > ChrisC
> >
> >
>
>


Reply | Threaded
Open this post in threaded view
|

RE: Lua on the PlayStation2

Nick Trout
In reply to this post by Chris Chapman

> From: Leigh McRae 
> Sent: Tuesday, October 07, 2003 11:28 AM
> To: Lua list
> Subject: Re: Lua on the PlayStation2
> 
>   I didn't see a eq metamethod for Lua 4.  I will check again, if so I
> will
> use this.  I did write a function called AreEqual() for the scripters
but
> I
> felt dirty and it was really prone to error.
> 
>   Casting the value of a handle to a void pointer would work, as a
> previous
> post suggested.  Looking back on the problem, I am thinking that it
was
> more
> of a tolua issue I was having.  I ended up changing tolua to treat
Handles
> as numbers when maybe what I really wanted was void pointers.  I will
have
> to look at it again, thanks for the ideas.


That sounds like a better idea as I think toLua coerces number types
back to their basic type so I don't think you can type check using
typedef'd number types that are floating point. 

In Lua 4 changing the type to void* will create a new tagged type which
you could type check in your AreEqual() function. You might also create
HandleId() and HandleInstance() which extract the appropriate
information from the "pointer".

In Lua 5.0 you will to have to create a heavy data type for each handle
to use the equals metamethod. You can use light user data (basically a
pointer wrapper) to do the same as the above Lua 4 method. The light
user data was created because some users were storing object pointers in
doubles and there is obviously no type safety.

Nick

TD R*V