PowerPC port for company
Locked
|
Hello,
I'm attempting a port of eLua for my company. We use micro's with the PowerPC architecture. We also have a software platform that I need eLua to work with. I have a few problems I'm hoping the community here might be able to help with. Our platform and specific micros do not support dynamic memory allocation, or at least not heavily. We also don't have a file system. We also don't support reentrancy. As such, I've been getting a lot of build errors which seem related to these features. From what I've come across in trying to port eLua, it seems memory allocation, file systems, and reentrancy are vital to its function. I have a few specific questions, if anybody can possibly help... 1) I've been getting a few errors about malloc() and free(). Specifically, I'm getting some multiple definition errors between malloc.o and mallocr.o, both of which are within libc.a. This isn't quite an eLua problem, but I've been trying to prevent linking to mallocr.o since this specific malloc deals with reentrancy, which we don't support. Does anybody know if it is possible to prevent linking to a specific object file from within a library file? 2) If the above question cannot be solved, I'm considering trying to remove the dynamic memory allocation code from eLua. Our platform/micros shouldn't support it anyways, and so I'm pushing the limits by trying any solution that keeps the code included. But in the case I have to de-couple any use of malloc, will this be critically detrimental to the proper functioning of eLua? 3) I've been getting persistent errors with this thing called _impure_ptr. The code in our GCC files say this thing is externally defined, but I can't find anywhere where it is actually defined. Is it possible we just aren't using enough/the right library files? I have tried to removed the places in code where it was being used, but this only caused a slew of more errors. Any advice on this? Specifics that may be helpful: Using GCC and linker 4.7.2. Not using a build system or tool chain, just a MS batch file. Running Windows XP, but other desktops here are running Windos 7. We do not use all of newlib, but I don't know quantitatively how much of it we use. Thanks in advance for any help. |
|
|
Hi,
Quick answer to your questions: it's pretty much impossible to run (e)Lua in a system that doesn't support dynamic memory allocation, as Lua itself makes extensive use of that. Furthermore, I can't think of an acceptable way to modify Lua to satisfy this restriction. Sorry for the bad news.
Best, Bogdan On Mon, May 19, 2014 at 3:41 PM, billson555 <[hidden email]> wrote: Hello, _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Thank you. If that is the case, I think that definitely helps to shape how I proceed from here. Could you possibly shed any light on the _impure_ptr issue? Is this related to reentrancy?
Thanks again Billson555 On Mon, May 19, 2014 at 6:07 PM, BogdanM [via eLua Development] <[hidden email]> wrote:
Will Johnson Cell: 1-616-808-1692 Email: [hidden email]
|
|
|
>Thank you. If that is the case, I think that definitely helps to shape how I proceed from here. >Could you possibly shed any light on the _impure_ptr issue? Is this related to reentrancy?
see google search results) but is probably due to the library you are trying to force the compiler to use. My gut feeling is unless you're going to write code in straight C, you've committed yourself to accepting dynamic memory allocation. That said, you're better off letting a language like lua handle that than doing it yourself manually. I'm betting lua does a better job with memory allocation than the typical embedded project handles pointers and shared memory. Matt _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by billson555
Just to clarify:
We were intending on sending Lua script over some yet un-chosen connection protocol to run some tests on our hardware. Are you saying that it would be impossible to run eLua without dynamic memory allocation, even if our Lua script tests didn't use any dynamic memory allocation? I just want to be as sure as I can before I have to make any dramatic shifts in strategy. Thank you |
|
|
Hi - It's not eLua that adds the requirement for dynamic memory allocation, Lua itself requires and makes extensive use of dynamic memory allocation. Lua runs all the dynamic memory management through realloc (since it can basically perform all the functions of malloc/realloc/free with just realloc). If you only have malloc and free you can work around implementing realloc functionality:
Lua will allocate memory for buffers to store your script in when you compile it, it will have to allocate memory to store the resulting bytecode and it will have to allocate memory for variables/functions/etc.. that are created and assigned as you go along. Even if the variable assignment you do doesn't require a new allocation it's using Lua's stack which is dynamically allocated. You might be doing things in Lua that look like what would be stack allocations in C, but in the Lua VM it's using dynamic memory allocation
You certainly don't need an MMU (most of our targets don't have one). Is there a reason why you might not be able to set aside a heap for Lua and point an existing malloc implementation at it (like the dlmalloc included with eLua)?
On Tue, May 20, 2014 at 8:32 AM, billson555 <[hidden email]> wrote: Just to clarify: James Snyder
ph: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
That might be a possibility. Unfortunately I am still relatively new to our platform; I have only been told by some fellow engineers that our platform/micros aren't meant to implement dynamic memory allocation, but at least one thinks it is a possibility. Nobody has explained to me the finer details of it. Since Lua obviously deals a lot with memory allocation, and at the same time it sounds like we're sticking with this option, we'll probably have to come up with a solution like your suggestion. Thanks On Wed, May 21, 2014 at 1:23 PM, James Snyder <[hidden email]> wrote:
Will Johnson Cell: 1-616-808-1692
Email: [hidden email]
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On 21/05/2014, Will Johnson <[hidden email]> wrote:
> On Wed, May 21, 2014 at 1:23 PM, James Snyder <[hidden email]>wrote: >> On Tue, May 20, 2014 at 8:32 AM, billson555 <[hidden email]>wrote: >>> Are you saying that it would be >>> impossible to run eLua without dynamic memory allocation, even if our Lua >>> script tests didn't use any dynamic memory allocation? >> >> You certainly don't need an MMU (most of our targets don't have one). Is >> there a reason why you might not be able to set aside a heap for Lua and >> point an existing malloc implementation at it (like the dlmalloc included >> with eLua)? Hi Your system doesn't need to supply dynamic memory allocation as eLua does this for you. It has an internal version of _sbrk() which replaces the operating system's one and gives out the requested memory from a static list of available memory regions. So all you need to do is to say where the available heap mempry is and the allcoator you choose (simple,multiple or newlib) should do the rest. Actually, this area could be improved, since Lua calls malloc(), malloc() calls sbrk() asking for ever-increasing amounts of memory for its heap and sbrk() returns a pointer to the predefined RAM areas. malloc(), for its version of the heap, asks for more and more memory from sbrk() using an algorithm with an increasing increment until the call fails, then thinks it has all the memory, whereas the three allocators would be happier to be allocated all the available RAM at startup, which would also mean they got all of it, not all of it execpt the last fragment. The available mamory regions are defined, for example, in the generated file boards/headers/board_mizar32b.h // Configuration for element 'ram' #define MEM_START_ADDRESS { ( u32 )( INTERNAL_RAM1_FIRST_FREE ),( ( u32 )( SDRAM + ELUA_FIRMWARE_SIZE ) ) } #define MEM_END_ADDRESS { ( u32 )( INTERNAL_RAM1_LAST_FREE ),( ( u32 )( SDRAM + ELUA_FIRMWARE_SIZE ) + ( u32 )( SDRAM_SIZE - ELUA_FIRMWARE_SIZE ) - 1 ) } As for re-entrancy, I'd guess that as long as your system doesn't use Lua interrupts you may be OK, as the Lua interpreter is single-threaded. For any interrupt routines you need, you'll just have to be careful what function calls they make, ideally none! Hope this gives you somewhere to start M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |