[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: lua - running bytecode from an external ram space
- From: Bogdan Marinescu <bogdan.marinescu@...>
- Date: Thu, 14 Jul 2011 10:12:05 +0300
On Thu, Jul 14, 2011 at 2:42 AM, Mike Panetta <firstname.lastname@example.org>
On Wed, Jul 13, 2011 at 7:30 PM, imo <email@example.com>
> Look at NXP'sRob, yes, there are "big" controllers with memory bus available. As
> LPC range: available up to 256kB of RAM and a
> local memory bus should you need more.
I am running pic32Lua on a pic32mx695 (128kB of internal ram) and I
know the eLua is also coping desperately with the ram shortage on
those smaller ARMs, I've been curious whether an access from the VM
to the bytecode via an user defined generic ramwr/ramrd c-functions
are easy to implement (as this can create an access to any hw ram
implementation of any bytecode size) or not. It seems it would be
very difficult, moreover, there is a low demand for such change in
the VM. The Lua is running fast on pic32mx, however the 100kB
internal ram available for the bytecode is not big enough for any
larger project. FYI - the "life.lua" with LIFE(32,32) fills the ram
Does that processor have something like the memory protection unit on the arms? You could easily change the Lua allocator to use your own function that 'allocates' from a protected region and use the fault handler to do the access.
I don't know of any MCU with a MMU. You're much more likely to find one on embedded CPUs that are designed specifically to run an OS like Linux or WinCE. I tried to simulate a MMU on a Cortex-M3 using its memory protection and flash patch units, but the result (besides being completely insane) was _extremely_ slow. The good news is that on-chip RAM is getting larger and larger as new CPUs emerge, which can only mean that Lua will feel very comfortable while running on them.