Lua Scripting Integration

fudgey

1705
a570is

Re: Lua Scripting Integration

« Reply #40 on: 19 / October / 2008, 15:56:15 »

Advertisements

What's the current status of execution speed of Lua? I like to know how fast or slow my scripts will run but currently I can only guess. For ubasic it's "all non-whitespace lines take 10 ms except for consecutive rem lines, who only take 10 ms to run per block of up to 100 lines", and something more complex for Lua, obviously.

From above I can see sleep() makes Lua wait for the next tick that loops may create automatic "sleeps" to prevent lockups (But when? At each iteration?). I somehow remember someone saying that some commands related to camera functionality do this as well (like shoot(), obviously) but couldn't find on a quick search.

This information should go to the wiki of course.

Another thing that should be documented is how large numbers we can use. I assume it's +-2^15 or +-2^31, one short from one (negative?) end (this one we're missing in our ubasic documentation as well).

Logged

fe50

3139
IXUS50 & 860, SX10 Star WARs-Star RAWs

Re: Lua Scripting Integration

« Reply #41 on: 19 / October / 2008, 17:08:55 »

Quote from: fudgey on 19 / October / 2008, 15:56:15

...
Another thing that should be documented is how large numbers we can use. I assume it's +-2^15 or +-2^31, one short from one (negative?) end (this one we're missing in our ubasic documentation as well).

From the wikia, uBASIC_syntax#uBASIC_Syntax_short_manual:
Variables: lower latin letter from a to z. 32 bit signed integer (-2147483648 to +2147483647).

I wrote this with the informations from reyalp:

Quote from: reyalp on 12 / September / 2008, 02:41:43

It should be a 32 bit int, +2147483647 -2147483648

Ubasic does use shorts in some places, but not for variables as far as I can tell.

Logged

-->FIRMWARE DUMPS<-- * Manual * Lua * me

reyalp

13840

Re: Lua Scripting Integration

« Reply #42 on: 19 / October / 2008, 17:56:20 »

Quote from: fudgey on 19 / October / 2008, 15:56:15

From above I can see sleep() makes Lua wait for the next tick that loops may create automatic "sleeps" to prevent lockups (But when? At each iteration?). I somehow remember someone saying that some commands related to camera functionality do this as well (like shoot(), obviously) but couldn't find on a quick search.

in ubasic, labels are treated similarly to rem lines.

It looks to me like the following yield (and thus wait for another 10ms cycle):
shoot
sleep (duh

)
click, press, release
wait_click
md_detect_motion

Additionally, a "count hook" is used so that lua will yield every 1000 lua VM instructions (with some exceptions that I'm not totally clear on.) You can't easily tell how many VM instructions a bit of lua code turns into, but in general every keyword, variable reference, operator or function call will turn into one or more. Comments and whitespace are taken care of by the compiler, so you don't have to worry about them.

Note that you can check execution time using get_tick_count, although the resolution is limited to 10ms.

e.g.
t0=get_tick_count()
... do the stuff you want to time
print("time: ",get_tick_count()-t0)

One thought that has occurred to me, for both languages, is that we could just sleep based on execution time. Maybe the 10ms resolution of get_tick_count would be a problem ? I don't suppose ARM has anything like an x86 TSC ?

I'm glad you brought this up, because I should probably also make the file IO stuff sleep too.

Quote

Another thing that should be documented is how large numbers we can use. I assume it's +-2^15 or +-2^31, one short from one (negative?) end (this one we're missing in our ubasic documentation as well).

CHDK Lua numbers are 32 bit signed ints.

Logged

Don't forget what the H stands for.

Velo

Re: Lua Scripting Integration

« Reply #43 on: 20 / October / 2008, 03:05:20 »

Quote from: reyalp on 19 / October / 2008, 17:56:20

It looks to me like the following yield (and thus wait for another 10ms cycle):
shoot
sleep (duh )
click, press, release
wait_click
md_detect_motion

Exactly. This is because some event is scheduled in the internal queue. Lua resumes, when the queue is empty again.

Quote from: reyalp on 19 / October / 2008, 17:56:20

Additionally, a "count hook" is used so that lua will yield every 1000 lua VM instructions (with some exceptions that I'm not totally clear on.) You can't easily tell how many VM instructions a bit of lua code turns into, but in general every keyword, variable reference, operator or function call will turn into one or more. Comments and whitespace are taken care of by the compiler, so you don't have to worry about them.

The count hook isn't strictly necessary. As long as you don't write loops that contain no yield-functions (see above). My first version of the patch hadn't this hook and it was easy to freeze the cam with scripts like:

Code: [Select]

while not is_pressed "up" do
end

If you use sleep(0) in this loops you don't need the count hook.

The exception you mentioned in the count hook has to do with yielding across c-calls. Yielding from the count-hook is more or less an undocumented feature. But it only works when there are no c-frames on the call stack.
This shouldn't be possible now, because you have to have a callstack like this Lua->C->Lua. But if some later patch introduces callbacks from C->lua everything should work fine.

Logged

fudgey

1705
a570is

Re: Lua Scripting Integration

« Reply #44 on: 20 / October / 2008, 15:17:29 »

Thanks for the answers you all!

Quote from: reyalp on 19 / October / 2008, 17:56:20

Additionally, a "count hook" is used so that lua will yield every 1000 lua VM instructions (with some exceptions that I'm not totally clear on.) You can't easily tell how many VM instructions a bit of lua code turns into, but in general every keyword,

I take this count is cleared each time sleep() or one of the other commands you listed are executed so this will never happen with code that has "enough" sleep creating commands in it?

Quote from: reyalp on 19 / October / 2008, 17:56:20

One thought that has occurred to me, for both languages, is that we could just sleep based on execution time. Maybe the 10ms resolution of get_tick_count would be a problem ? I don't suppose ARM has anything like an x86 TSC ?

I once spent a little while looking for a timer that would update faster (working on the assumption that a faster clock has to be responsible of updating that 10 ms ticker be it via an interrupt or something else) and be very likely readable but couldn't find anything. But that's very much probably just because I really didn't know where and how to look.

I'm no expert in ARM so please enlighten me if I'm wrong, but I've understood that ARM cores are pretty much just cores, and as such any peripherals like timers are pretty much implementation specific and handled as co-processors, meaning that it's hard to know how to access the Digic processor peripherals unless they are following some industry convention unknown to me. Of course we have disassemblies to dig into for all that...

A timer interrupt would have no debug strings to slow it down making it harder to find unless ARM has restrictions for placing them (looks like wdt things are pretty early in our dumps for instance)?

Logged

reyalp

13840

Re: Lua Scripting Integration

« Reply #45 on: 21 / October / 2008, 00:23:51 »

Quote from: fudgey on 20 / October / 2008, 15:17:29

I take this count is cleared each time sleep() or one of the other commands you listed are executed so this will never happen with code that has "enough" sleep creating commands in it?

AFAIK, no (the reason being that lua itself handles the counting can calling the hook)

There are several ways this could be improved, but it's probably not urgent. If you have script that it causes problems for, that would be a different story.

Logged

Don't forget what the H stands for.

fudgey

1705
a570is

Re: Lua Scripting Integration

« Reply #46 on: 21 / October / 2008, 12:46:57 »

Quote from: reyalp on 21 / October / 2008, 00:23:51

Quote from: fudgey on 20 / October / 2008, 15:17:29
I take this count is cleared each time sleep() or one of the other commands you listed are executed so this will never happen with code that has "enough" sleep creating commands in it?
AFAIK, no (the reason being that lua itself handles the counting can calling the hook)

There are several ways this could be improved, but it's probably not urgent. If you have script that it causes problems for, that would be a different story.

Urgent? No, I don't think so either. But two things come to mind:

Remote control codes. To overcome our limitation of only having 1 slow input line (USB supply voltage) which ubasic is able to poll with 10 ms period, some users have use pulse width to code commands. This "random" sleep occasionally causes 10 ms additional jitter to that communication. If I'm not mistaken, that won't be the greatest inaccuracy, though. Has anyone tried these scripts in Lua yet?

The other one is more of a research project. There's a thread out there somewhere with cyril4e (if my mind serves) and myself looking at an alternative for propcase 205/206 shoot status, to improve the information and get rid of problems with Ae lock, for instance. That test (sampling a value of a variable in the camera to find out what values it gets and when and for how long) could be done with much greater precision using Lua and maybe the new I/O commands, but a "random" 10 ms delay interferes. That can of course be worked around by changing something in the script to make it sleep at different times and running the tests again (which needs to be done anyway I suppose, it's just more convenient to know exactly when the script is asleep).

Logged