lua on ARM7

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

lua on ARM7

bert-6
Hi All,

I have an ARM cpu here I'd like to run LUA on. I'd like the LUA part of the firmware to take less than 32K, and I don't need the complete LUA running on it. I just want to write some LUA function on my PC and then run the (compiled) code on LUA running on the ARM. The function typically does some computations on data. What parts of the LUA source code do I need for making this work and what can I safely remove?

Thanks,
Bert.


Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

Asko Kauppi

This is a re-occurring issue, so you might want to search the list archives for old discussions (there's no real change to this, since Lua 4.0 at least).  What you'd want to "pick and place" is all the standard libraries, that's for sure.  Even then, I wouldn't think 32K is really reachable, some 50-60K might be.  Others may prove me wrong. :)

-asko


bert kirjoitti 13.5.2006 kello 2.44:

Hi All,

I have an ARM cpu here I'd like to run LUA on. I'd like the LUA part of the firmware to take less than 32K, and I don't need the complete LUA running on it. I just want to write some LUA function on my PC and then run the (compiled) code on LUA running on the ARM. The function typically does some computations on data. What parts of the LUA source code do I need for making this work and what can I safely remove?

Thanks,
Bert.


Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.

Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

Alex Queiroz
In reply to this post by bert-6
Hallo,

On 5/12/06, bert <[hidden email]> wrote:
>[...]
> computations on data. What parts of the LUA source code do I need for making
> this work and what can I safely remove?
>

     This is for Lua 4.0, but may get you started:

http://www.lua.org/notes/ltn002.html

--
-alex
http://www.ventonegro.org/
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

Luiz Henrique de Figueiredo
> What parts of the LUA source code do I need for making
> this work and what can I safely remove?
>      This is for Lua 4.0, but may get you started:
>
> http://www.lua.org/notes/ltn002.html

Yes, and Lua 5.x this is even easier. See etc/noparser.c
This will save you some 30% of the core code.
--lhf
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

bert-6
Hi All,
 
thanks a lot for the helpful replies. I tried compiling LUA and it is true that I end up at over 30K but less than 64K of code. that is compiling in thumb mode so I suspect that it will be even more if I try ARM mode. I have tried with the IAR EW compiler, still have to try the GCC.
 
Now, the firmware would be running LUA code in an interrupt. How would this be done to keep things thread-safe (nested interrupts?), and is it realistic to call a LUA function from an interrupt routine being called at 30kHz?
 
It somehow makes more sense to me to compile the LUA code on my host PC to something that can be run very efficiently on the ARM platform, like native code, but then I'm not sure how difficult it is to compile LUA code to native ARM directly.
 
Thanks,
Bert


Luiz Henrique de Figueiredo <[hidden email]> wrote:
> What parts of the LUA source code do I need for making
> this work and what can I safely remove?
> This is for Lua 4.0, but may get you started:
>
> http://www.lua.org/notes/ltn002.html

Yes, and Lua 5.x this is even easier. See etc/noparser.c
This will save you some 30% of the core code.
--lhf


Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2¢/min with Yahoo! Messenger with Voice.
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

David Brown-4
Hi Bert,

I haven't done much with Lua yet, but I've plenty of experience with
embedded systems.  Calling an interpreted language from an interrupt running
at that speed sounds like a bad idea.  30 kHz is pretty fast - even for an
ARM.  Depending on the type of ARM and its clock speed, you have something
like 1000 to 10000 clock cycles between interrupts.  That's not a lot when
you are running an interpreter.  At best, you will use a large proportion of
your cpu time, and will get very large jitter.  In particular, garbage
collection may cause occasional extra delays.

If you really need to run lua scripts triggered by interrupts, you are
probably better off setting a flag in the interrupt routine, and using that
to start the script from within your main loop.

mvh.,

David



----- Original Message -----
From: bert
To: Lua list
Sent: Monday, May 15, 2006 9:05 AM
Subject: Re: lua on ARM7


Hi All,

thanks a lot for the helpful replies. I tried compiling LUA and it is true
that I end up at over 30K but less than 64K of code. that is compiling in
thumb mode so I suspect that it will be even more if I try ARM mode. I have
tried with the IAR EW compiler, still have to try the GCC.

Now, the firmware would be running LUA code in an interrupt. How would this
be done to keep things thread-safe (nested interrupts?), and is it realistic
to call a LUA function from an interrupt routine being called at 30kHz?

It somehow makes more sense to me to compile the LUA code on my host PC to
something that can be run very efficiently on the ARM platform, like native
code, but then I'm not sure how difficult it is to compile LUA code to
native ARM directly.

Thanks,
Bert


Luiz Henrique de Figueiredo <[hidden email]> wrote:
> What parts of the LUA source code do I need for making
> this work and what can I safely remove?
> This is for Lua 4.0, but may get you started:
>
> http://www.lua.org/notes/ltn002.html

Yes, and Lua 5.x this is even easier. See etc/noparser.c
This will save you some 30% of the core code.
--lhf





Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2¢/min
with Yahoo! Messenger with Voice.


Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

Asko Kauppi

Yes, Bert's situation sounds challenging (maybe to the degree of  
foolishness? :) to say the least.

I would consider doing an "event dispatch" interrupt handler (in C)  
that would sit in the other end of a FIFO queue, the other end being  
polled by Lua (can you run one instance, as the main loop?) to take  
in "commands". Of course, those commands can be full  Lua scriptlets,  
nothing's preventing that. But the point would be, you end up having  
them in the queue, so getting multiple interrupts won't be an issue  
(unless the queue grows and grows and... then you have too slow a CPU  
anyways ;)

Hope this helps, still thinking you'll never fit Lua in 30kB  
binary. :P  Please prove me wrong.

-asko


David Brown kirjoitti 15.5.2006 kello 14.19:

> Hi Bert,
>
> I haven't done much with Lua yet, but I've plenty of experience with
> embedded systems.  Calling an interpreted language from an  
> interrupt running
> at that speed sounds like a bad idea.  30 kHz is pretty fast - even  
> for an
> ARM.  Depending on the type of ARM and its clock speed, you have  
> something
> like 1000 to 10000 clock cycles between interrupts.  That's not a  
> lot when
> you are running an interpreter.  At best, you will use a large  
> proportion of
> your cpu time, and will get very large jitter.  In particular, garbage
> collection may cause occasional extra delays.
>
> If you really need to run lua scripts triggered by interrupts, you are
> probably better off setting a flag in the interrupt routine, and  
> using that
> to start the script from within your main loop.
>
> mvh.,
>
> David
>
>
>
> ----- Original Message -----
> From: bert
> To: Lua list
> Sent: Monday, May 15, 2006 9:05 AM
> Subject: Re: lua on ARM7
>
>
> Hi All,
>
> thanks a lot for the helpful replies. I tried compiling LUA and it  
> is true
> that I end up at over 30K but less than 64K of code. that is  
> compiling in
> thumb mode so I suspect that it will be even more if I try ARM  
> mode. I have
> tried with the IAR EW compiler, still have to try the GCC.
>
> Now, the firmware would be running LUA code in an interrupt. How  
> would this
> be done to keep things thread-safe (nested interrupts?), and is it  
> realistic
> to call a LUA function from an interrupt routine being called at  
> 30kHz?
>
> It somehow makes more sense to me to compile the LUA code on my  
> host PC to
> something that can be run very efficiently on the ARM platform,  
> like native
> code, but then I'm not sure how difficult it is to compile LUA code to
> native ARM directly.
>
> Thanks,
> Bert
>
>
> Luiz Henrique de Figueiredo <[hidden email]> wrote:
>> What parts of the LUA source code do I need for making
>> this work and what can I safely remove?
>> This is for Lua 4.0, but may get you started:
>>
>> http://www.lua.org/notes/ltn002.html
>
> Yes, and Lua 5.x this is even easier. See etc/noparser.c
> This will save you some 30% of the core code.
> --lhf
>
>
>
>
>
> Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for  
> just 2¢/min
> with Yahoo! Messenger with Voice.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

David Given
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Asko Kauppi wrote:
[...]
> I would consider doing an "event dispatch" interrupt handler (in C) that
> would sit in the other end of a FIFO queue, the other end being polled
> by Lua (can you run one instance, as the main loop?) to take in
> "commands".
[...]

A common technique is to have the interrupt handler set a bit to say
'this interrupt has happened'. Your userspace code then polls all the
various bits, does its work, and then clears them again. Getting the
logic right to ensure that all interrupts are properly serviced is a bit
challenging, and of course you lose any kind of real-time-ness, but it
does allow you to avoid having to allocate memory during your interrupt
handler.

- --
+- David Given --McQ-+ "Preacher, don't the Bible have some pretty
|  [hidden email]    | specific things to say about killing?" "Quite
| ([hidden email]) | specific. It is, however, somewhat fuzzier on the
+- www.cowlark.com --+ subject of kneecaps." --- Firefly, _War Stories_
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEaLObf9E0noFvlzgRAlGlAKCHJLWZEJLwpJc1dClRqsKv4peCpACbBVNC
ss1D++Qj01M4FYoe6g6DD5w=
=lHJf
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

Asko Kauppi

Ah, yeah.

Your flag thing is a "one entry queue" but I was expecting Bert not  
to want to lose a single interrupt (and them to be different, like  
having some data values attached, that Lua would care about).

Anyways, already this is getting speculative, since we don't know  
what Bert does. Bert: if you want an event dispatch queue, I can send  
code I've used in LuaX/SDL_mixer, to catch played music samples at  
real time (and show the graphs by Lua). Don't remember about memory  
allocation, but yes, most likely one alloc per interrupt is needed  
there.

-asko


David Given kirjoitti 15.5.2006 kello 20.00:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Asko Kauppi wrote:
> [...]
>> I would consider doing an "event dispatch" interrupt handler (in  
>> C) that
>> would sit in the other end of a FIFO queue, the other end being  
>> polled
>> by Lua (can you run one instance, as the main loop?) to take in
>> "commands".
> [...]
>
> A common technique is to have the interrupt handler set a bit to say
> 'this interrupt has happened'. Your userspace code then polls all the
> various bits, does its work, and then clears them again. Getting the
> logic right to ensure that all interrupts are properly serviced is  
> a bit
> challenging, and of course you lose any kind of real-time-ness, but it
> does allow you to avoid having to allocate memory during your  
> interrupt
> handler.
>
> - --
> +- David Given --McQ-+ "Preacher, don't the Bible have some pretty
> |  [hidden email]    | specific things to say about killing?" "Quite
> | ([hidden email]) | specific. It is, however, somewhat fuzzier  
> on the
> +- www.cowlark.com --+ subject of kneecaps." --- Firefly, _War  
> Stories_
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEaLObf9E0noFvlzgRAlGlAKCHJLWZEJLwpJc1dClRqsKv4peCpACbBVNC
> ss1D++Qj01M4FYoe6g6DD5w=
> =lHJf
> -----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

Lisa Parratt
Asko Kauppi wrote:

> Ah, yeah.
>
> Your flag thing is a "one entry queue" but I was expecting Bert not to
> want to lose a single interrupt (and them to be different, like having
> some data values attached, that Lua would care about).
>
> Anyways, already this is getting speculative, since we don't know what
> Bert does. Bert: if you want an event dispatch queue, I can send code
> I've used in LuaX/SDL_mixer, to catch played music samples at real
> time (and show the graphs by Lua). Don't remember about memory
> allocation, but yes, most likely one alloc per interrupt is needed there.
Or you allocate a buffer up front, and increase the size in the user
space receiver once >n% has been used. Never a good idea to allocate
during an interrupt, and often not allowed on many systems.

--
Lisa
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

bert-6
In reply to this post by Asko Kauppi
Hi Asko, all,

Sorry, I've been out of the office for a few days and not keeping up with this thread.

Anyway, I'm definately interested in that SDL_mixer example.. might help clear up some stuff.

I was thinking of using LUA to process samples from the ARM's on-board analog-to-digital converter, but it looks like that would be asking too much.

So my next question is.. how hard is it to compile LUA to ARM7 assembly :-)
maybe Thumb mode ...

I realize it would be very complicated, since you would need the garbage collector. but what if I limit it to compiling a LUA function like this :

    function process(input1, input2)
       return input1 * input2
    end

I guess that wouldn't be too hard? I'm not sure if there exists a lua scanner/parser in LUA itself...

what if it gets more complicated:

    lut = [0, 0, 0, 0, ... 0]      --- say, 256 values in lut

    function process(input)
       return lut [ input ]
    end

or what about this :

    function process(input)
       local t = [math.random(), math.random(), math.random()]
       return input * t[math.random(3)]
    end

I know these functions don't make a lot of sense but I'm trying to get a general idea of how to go about this.

I'd like to have some function in LUA that does something like this

    funBinaryCode = compileARM(function (input1, input2) return input1*input2 end)

--- funBinaryCode now holds a table of bytes which can be cast to a function pointer on the ARM7 and called

Any comments highly appreciated.

Bert


Asko Kauppi <[hidden email]> wrote:

Ah, yeah.

Your flag thing is a "one entry queue" but I was expecting Bert not
to want to lose a single interrupt (and them to be different, like
having some data values attached, that Lua would care about).

Anyways, already this is getting speculative, since we don't know
what Bert does. Bert: if you want an event dispatch queue, I can send
code I've used in LuaX/SDL_mixer, to catch played music samples at
real time (and show the graphs by Lua). Don't remember about memory
allocation, but yes, most likely one alloc per interrupt is needed
there.

-asko


David Given kirjoitti 15.5.2006 kello 20.00:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Asko Kauppi wrote:
> [...]
>> I would consider doing an "event dispatch" interrupt handler (in
>> C) that
>> would sit in the other end of a FIFO queue, the other end being
>> polled
>> by Lua (can you run one instance, as the main loop?) to take in
>> "commands".
> [...]
>
> A common technique is to have the interrupt handler set a bit to say
> 'this interrupt has happened'. Your userspace code then polls all the
> various bits, does its work, and then clears them again. Getting the
> logic right to ensure that all interrupts are properly serviced is
> a bit
> challenging, and of course you lose any kind of real-time-ness, but it
> does allow you to avoid having to allocate memory during your
> interrupt
> handler.
>
> - --
> +- David Given --McQ-+ "Preacher, don't the Bible have some pretty
> | [hidden email] | specific things to say about killing?" "Quite
> | ([hidden email]) | specific. It is, however, somewhat fuzzier
> on the
> +- www.cowlark.com --+ subject of kneecaps." --- Firefly, _War
> Stories_
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEaLObf9E0noFvlzgRAlGlAKCHJLWZEJLwpJc1dClRqsKv4peCpACbBVNC
> ss1D++Qj01M4FYoe6g6DD5w=
> =lHJf
> -----END PGP SIGNATURE-----



Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

David Brown-4
If you are doing embedded development, you have to learn C - there's no way round it.  Use C for the low-level stuff and the time-critical stuff.  Lua can make sense for higher level coding, especially for code that might change often.
 
Mixing C and Lua is not hard - I suppose that's one of the main points about using Lua in the first place.
 
mvh.,
 
David
 
 
----- Original Message -----
Sent: Thursday, May 18, 2006 8:12 PM
Subject: Re: lua on ARM7

Hi Asko, all,

Sorry, I've been out of the office for a few days and not keeping up with this thread.

Anyway, I'm definately interested in that SDL_mixer example.. might help clear up some stuff.

I was thinking of using LUA to process samples from the ARM's on-board analog-to-digital converter, but it looks like that would be asking too much.

So my next question is.. how hard is it to compile LUA to ARM7 assembly :-)
maybe Thumb mode ...

I realize it would be very complicated, since you would need the garbage collector. but what if I limit it to compiling a LUA function like this :

    function process(input1, input2)
       return input1 * input2
    end

I guess that wouldn't be too hard? I'm not sure if there exists a lua scanner/parser in LUA itself...

what if it gets more complicated:

    lut = [0, 0, 0, 0, ... 0]      --- say, 256 values in lut

    function process(input)
       return lut [ input ]
    end

or what about this :

    function process(input)
       local t = [math.random(), math.random(), math.random()]
       return input * t[math.random(3)]
    end

I know these functions don't make a lot of sense but I'm trying to get a general idea of how to go about this.

I'd like to have some function in LUA that does something like this

    funBinaryCode = compileARM(function (input1, input2) return input1*input2 end)

--- funBinaryCode now holds a table of bytes which can be cast to a function pointer on the ARM7 and called

Any comments highly appreciated.

Bert


Asko Kauppi <[hidden email]> wrote:

Ah, yeah.

Your flag thing is a "one entry queue" but I was expecting Bert not
to want to lose a single interrupt (and them to be different, like
having some data values attached, that Lua would care about).

Anyways, already this is getting speculative, since we don't know
what Bert does. Bert: if you want an event dispatch queue, I can send
code I've used in LuaX/SDL_mixer, to catch played music samples at
real time (and show the graphs by Lua). Don't remember about memory
allocation, but yes, most likely one alloc per interrupt is needed
there.

-asko


David Given kirjoitti 15.5.2006 kello 20.00:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Asko Kauppi wrote:
> [...]
>> I would consider doing an "event dispatch" interrupt handler (in
>> C) that
>> would sit in the other end of a FIFO queue, the other end being
>> polled
>> by Lua (can you run one instance, as the main loop?) to take in
>> "commands".
> [...]
>
> A common technique is to have the interrupt handler set a bit to say
> 'this interrupt has happened'. Your userspace code then polls all the
> various bits, does its work, and then clears them again. Getting the
> logic right to ensure that all interrupts are properly serviced is
> a bit
> challenging, and of course you lose any kind of real-time-ness, but it
> does allow you to avoid having to allocate memory during your
> interrupt
> handler.
>
> - --
> +- David Given --McQ-+ "Preacher, don't the Bible have some pretty
> | [hidden email] | specific things to say about killing?" "Quite
> | ([hidden email]) | specific. It is, however, somewhat fuzzier
> on the
> +- www.cowlark.com --+ subject of kneecaps." --- Firefly, _War
> Stories_
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEaLObf9E0noFvlzgRAlGlAKCHJLWZEJLwpJc1dClRqsKv4peCpACbBVNC
> ss1D++Qj01M4FYoe6g6DD5w=
> =lHJf
> -----END PGP SIGNATURE-----



Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

bert-6
I've been programming C and C++ for a very long time, and I wrote several LUA extensions already.
 
I just want to go straight from LUA to assembly, because I can't expect my users to learn C and they need to extend the functionality of the embedded platform.

David Brown <[hidden email]> wrote:
If you are doing embedded development, you have to learn C - there's no way round it.  Use C for the low-level stuff and the time-critical stuff.  Lua can make sense for higher level coding, especially for code that might change often.
 
Mixing C and Lua is not hard - I suppose that's one of the main points about using Lua in the first place.
 
mvh.,
 
David
 
 
----- Original Message -----
Sent: Thursday, May 18, 2006 8:12 PM
Subject: Re: lua on ARM7

Hi Asko, all,

Sorry, I've been out of the office for a few days and not keeping up with this thread.

Anyway, I'm definately interested in that SDL_mixer example.. might help clear up some stuff.

I was thinking of using LUA to process samples from the ARM's on-board analog-to-digital converter, but it looks like that would be asking too much.

So my next question is.. how hard is it to compile LUA to ARM7 assembly :-)
maybe Thumb mode ...

I realize it would be very complicated, since you would need the garbage collector. but what if I limit it to compiling a LUA function like this :

    function process(input1, input2)
       return input1 * input2
    end

I guess that wouldn't be too hard? I'm not sure if there exists a lua scanner/parser in LUA itself...

what if it gets more complicated:

    lut = [0, 0, 0, 0, ... 0]      --- say, 256 values in lut

    function process(input)
       return lut [ input ]
    end

or what about this :

    function process(input)
       local t = [math.random(), math.random(), math.random()]
       return input * t[math.random(3)]
    end

I know these functions don't make a lot of sense but I'm trying to get a general idea of how to go about this.

I'd like to have some function in LUA that does something like this

    funBinaryCode = compileARM(function (input1, input2) return input1*input2 end)

--- funBinaryCode now holds a table of bytes which can be cast to a function pointer on the ARM7 and called

Any comments highly appreciated.

Bert


Asko Kauppi <[hidden email]> wrote:

Ah, yeah.

Your flag thing is a "one entry queue" but I was expecting Bert not
to want to lose a single interrupt (and them to be different, like
having some data values attached, that Lua would care about).

Anyways, already this is getting speculative, since we don't know
what Bert does. Bert: if you want an event dispatch queue, I can send
code I've used in LuaX/SDL_mixer, to catch played music samples at
real time (and show the graphs by Lua). Don't remember about memory
allocation, but yes, most likely one alloc per interrupt is needed
there.

-asko


David Given kirjoitti 15.5.2006 kello 20.00:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Asko Kauppi wrote:
> [...]
>> I would consider doing an "event dispatch" interrupt handler (in
>> C) that
>> would sit in the other end of a FIFO queue, the other end being
>> polled
>> by Lua (can you run one instance, as the main loop?) to take in
>> "commands".
> [...]
>
> A common technique is to have the interrupt handler set a bit to say
> 'this interrupt has happened'. Your userspace code then polls all the
> various bits, does its work, and then clears them again. Getting the
> logic right to ensure that all interrupts are properly serviced is
> a bit
> challenging, and of course you lose any kind of real-time-ness, but it
> does allow you to avoid having to allocate memory during your
> interrupt
> handler.
>
> - --
> +- David Given --McQ-+ "Preacher, don't the Bible have some pretty
> | [hidden email] | specific things to say about killing?" "Quite
> | ([hidden email]) | specific. It is, however, somewhat fuzzier
> on the
> +- www.cowlark.com --+ subject of kneecaps." --- Firefly, _War
> Stories_
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEaLObf9E0noFvlzgRAlGlAKCHJLWZEJLwpJc1dClRqsKv4peCpACbBVNC
> ss1D++Qj01M4FYoe6g6DD5w=
> =lHJf
> -----END PGP SIGNATURE-----



Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.


New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

David Brown-4
Hi Bert,
 
That makes more sense (I couldn't quite figure how someone would be doing embedded ARM development while trying to avoid C).
 
How about having your interrupts setting a flag, and having Lua (run from the main routine) set up with a co-routine that activates on the flag?  Obviously you are not going to get immediate response, but you will avoid things like race conditions.
 
As to converting Lua straight to assembly, I doubt if it would be easy to make a general solution.  You might be able to convert a useful subset of Lua to C (and then let the C compiler do the rest of the work), but I don't know enough of the implementation of Lua to help.
 
mvh.,
 
David
 
 
 
----- Original Message -----
Sent: Sunday, May 21, 2006 11:07 PM
Subject: Re: lua on ARM7

I've been programming C and C++ for a very long time, and I wrote several LUA extensions already.
 
I just want to go straight from LUA to assembly, because I can't expect my users to learn C and they need to extend the functionality of the embedded platform.

David Brown <[hidden email]> wrote:
If you are doing embedded development, you have to learn C - there's no way round it.  Use C for the low-level stuff and the time-critical stuff.  Lua can make sense for higher level coding, especially for code that might change often.
 
Mixing C and Lua is not hard - I suppose that's one of the main points about using Lua in the first place.
 
mvh.,
 
David
 
 
----- Original Message -----
Sent: Thursday, May 18, 2006 8:12 PM
Subject: Re: lua on ARM7

Hi Asko, all,

Sorry, I've been out of the office for a few days and not keeping up with this thread.

Anyway, I'm definately interested in that SDL_mixer example.. might help clear up some stuff.

I was thinking of using LUA to process samples from the ARM's on-board analog-to-digital converter, but it looks like that would be asking too much.

So my next question is.. how hard is it to compile LUA to ARM7 assembly :-)
maybe Thumb mode ...

I realize it would be very complicated, since you would need the garbage collector. but what if I limit it to compiling a LUA function like this :

    function process(input1, input2)
       return input1 * input2
    end

I guess that wouldn't be too hard? I'm not sure if there exists a lua scanner/parser in LUA itself...

what if it gets more complicated:

    lut = [0, 0, 0, 0, ... 0]      --- say, 256 values in lut

    function process(input)
       return lut [ input ]
    end

or what about this :

    function process(input)
       local t = [math.random(), math.random(), math.random()]
       return input * t[math.random(3)]
    end

I know these functions don't make a lot of sense but I'm trying to get a general idea of how to go about this.

I'd like to have some function in LUA that does something like this

    funBinaryCode = compileARM(function (input1, input2) return input1*input2 end)

--- funBinaryCode now holds a table of bytes which can be cast to a function pointer on the ARM7 and called

Any comments highly appreciated.

Bert


Asko Kauppi <[hidden email]> wrote:

Ah, yeah.

Your flag thing is a "one entry queue" but I was expecting Bert not
to want to lose a single interrupt (and them to be different, like
having some data values attached, that Lua would care about).

Anyways, already this is getting speculative, since we don't know
what Bert does. Bert: if you want an event dispatch queue, I can send
code I've used in LuaX/SDL_mixer, to catch played music samples at
real time (and show the graphs by Lua). Don't remember about memory
allocation, but yes, most likely one alloc per interrupt is needed
there.

-asko


David Given kirjoitti 15.5.2006 kello 20.00:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Asko Kauppi wrote:
> [...]
>> I would consider doing an "event dispatch" interrupt handler (in
>> C) that
>> would sit in the other end of a FIFO queue, the other end being
>> polled
>> by Lua (can you run one instance, as the main loop?) to take in
>> "commands".
> [...]
>
> A common technique is to have the interrupt handler set a bit to say
> 'this interrupt has happened'. Your userspace code then polls all the
> various bits, does its work, and then clears them again. Getting the
> logic right to ensure that all interrupts are properly serviced is
> a bit
> challenging, and of course you lose any kind of real-time-ness, but it
> does allow you to avoid having to allocate memory during your
> interrupt
> handler.
>
> - --
> +- David Given --McQ-+ "Preacher, don't the Bible have some pretty
> | [hidden email] | specific things to say about killing?" "Quite
> | ([hidden email]) | specific. It is, however, somewhat fuzzier
> on the
> +- www.cowlark.com --+ subject of kneecaps." --- Firefly, _War
> Stories_
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEaLObf9E0noFvlzgRAlGlAKCHJLWZEJLwpJc1dClRqsKv4peCpACbBVNC
> ss1D++Qj01M4FYoe6g6DD5w=
> =lHJf
> -----END PGP SIGNATURE-----



Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.


New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

bert-6
Hi All,

Continuing on the LUA on ARM thread... I've been thinking how I could run a subset of LUA in under 32K, and fast enough for RT applications. What if :

    - we don't want to support the lua standard libraries
    - we don't support dynamic memory allocation and leave out the garbage collector (so we need a special keyword to alloc all memory at boot time)
    - we use int32 instead of float as number type
    - we don't support the local keyword or variables that were not explicitly allocated at boot time

what parts of the LUA source distribution would I need to run the VM on the ARM and what can I leave out? I looked in the lopcodes.h and lvm.c and didn't see special instructions for memory allocation .. but then I haven't thoroughly studied all of the LUA code.

Thanks,
Bert
 


Be a chatter box. Enjoy free PC-to-PC calls with Yahoo! Messenger with Voice.
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

Lisa Parratt
bert wrote:
> Hi All,
>
> Continuing on the LUA on ARM thread... I've been thinking how I could
> run a subset of LUA in under 32K, and fast enough for RT applications.
Never going to happen.
> What if :
>
>     - we don't want to support the lua standard libraries
>     - we don't support dynamic memory allocation and leave out the
> garbage collector (so we need a special keyword to alloc all memory at
> boot time)
>     - we use int32 instead of float as number type
>     - we don't support the local keyword or variables that were not
> explicitly allocated at boot time
Why don't you add the following, while you're at it?
- the ability to raise the dead
- over unity power generation facilities
- faster than light travel

> what parts of the LUA source distribution would I need to run the VM
> on the ARM and what can I leave out? I looked in the lopcodes.h and
> lvm.c and didn't see special instructions for memory allocation .. but
> then I haven't thoroughly studied all of the LUA code.
That's because it's such a fundamental property of Lua that it's
implemented at a lower more ubiquitous level.

--
Lisa
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

Luiz Henrique de Figueiredo
In reply to this post by bert-6
>     - we don't want to support the lua standard libraries

Just don't open them.

>     - we don't support dynamic memory allocation and leave out the garbage collector (so we need a special keyword to alloc all memory at boot time)

Use your own memory allocator that gets memory from a fixed pool allocated
the first time it is called.

To avoid the garbage collector, you can write stubs for the functions exported
in lgc.h.

>     - we use int32 instead of float as number type

Edit luaconf.h

>     - we don't support the local keyword or variables that were not explicitly allocated at boot time

Edit llex.c and add a space before "local" in luaX_tokens. But that will
put all variables as global variables, which probably use more memory
than local variables...

To forbid creating global variables after boot time, set up a __newindex
metamethod for _G to raise an error.

> what parts of the LUA source distribution would I need to run the VM on the ARM and what can I leave out?

Try leaving out the parser modules by using etc/noparser.c.
--lhf
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

Romulo Bahiense
In reply to this post by Lisa Parratt
> Why don't you add the following, while you're at it?
> - the ability to raise the dead
> - over unity power generation facilities
> - faster than light travel

Ouch.

--rb
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

bert-6
In reply to this post by Lisa Parratt


Lisa Parratt <[hidden email]> wrote:
bert wrote:
> Hi All,
>
> Continuing on the LUA on ARM thread... I've been thinking how I could
> run a subset of LUA in under 32K, and fast enough for RT applications.
Never going to happen.
> What if :
>
> - we don't want to support the lua standard libraries
> - we don't support dynamic memory allocation and leave out the
> garbage collector (so we need a special keyword to alloc all memory at
> boot time)
> - we use int32 instead of float as number type
> - we don't support the local keyword or variables that were not
> explicitly allocated at boot time
Why don't you add the following, while you're at it?
- the ability to raise the dead
- over unity power generation facilities
- faster than light travel

Sorry, I'm afraid I can't do that because I don't have a glowy hippie outfit ...



> what parts of the LUA source distribution would I need to run the VM
> on the ARM and what can I leave out? I looked in the lopcodes.h and
> lvm.c and didn't see special instructions for memory allocation .. but
> then I haven't thoroughly studied all of the LUA code.
That's because it's such a fundamental property of Lua that it's
implemented at a lower more ubiquitous level.

--
Lisa


Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better.
Reply | Threaded
Open this post in threaded view
|

Re: lua on ARM7

bert-6
In reply to this post by Luiz Henrique de Figueiredo
Hi Luiz,

Thanks a lot for the helpful comments. I'm now down to 25K of code, after leaving out the standard libraries and the parser (using noparser.c). I didn't do any other modifications to the LUA code yet and I still have to do some testing.

Bert


Luiz Henrique de Figueiredo <[hidden email]> wrote:
> - we don't want to support the lua standard libraries

Just don't open them.

> - we don't support dynamic memory allocation and leave out the garbage collector (so we need a special keyword to alloc all memory at boot time)

Use your own memory allocator that gets memory from a fixed pool allocated
the first time it is called.

To avoid the garbage collector, you can write stubs for the functions exported
in lgc.h.

> - we use int32 instead of float as number type

Edit luaconf.h

> - we don't support the local keyword or variables that were not explicitly allocated at boot time

Edit llex.c and add a space before "local" in luaX_tokens. But that will
put all variables as global variables, which probably use more memory
than local variables...

To forbid creating global variables after boot time, set up a __newindex
metamethod for _G to raise an error.

> what parts of the LUA source distribution would I need to run the VM on the ARM and what can I leave out?

Try leaving out the parser modules by using etc/noparser.c.
--lhf


How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.
12