PowerPC port for company

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

PowerPC port for company

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.
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC port for company

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,

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.



--
View this message in context: http://elua-development.2368040.n2.nabble.com/PowerPC-port-for-company-tp7578410.html
Sent from the eLua Development mailing list archive at Nabble.com.
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
billson555 billson555
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC port for company

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:
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,

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.



--
View this message in context: http://elua-development.2368040.n2.nabble.com/PowerPC-port-for-company-tp7578410.html
Sent from the eLua Development mailing list archive at Nabble.com.
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev


If you reply to this email, your message will be added to the discussion below:
http://elua-development.2368040.n2.nabble.com/PowerPC-port-for-company-tp7578410p7578412.html
To unsubscribe from PowerPC port for company, click here.
NAML



--
Will Johnson
Cell: 1-616-808-1692
Pink Boy Pink Boy
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC port for company


Billson,

>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?

Looks like it has something to do do with task switching (could be wrong, but that's the context I
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
billson555 billson555
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC port for company

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
jbsnyder jbsnyder
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC port for company

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:

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



--
View this message in context: http://elua-development.2368040.n2.nabble.com/PowerPC-port-for-company-tp7578410p7578416.html
Sent from the eLua Development mailing list archive at Nabble.com.
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev



--
James Snyder
ph: (847) 448-0386

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
billson555 billson555
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC port for company

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:
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:

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



--
View this message in context: http://elua-development.2368040.n2.nabble.com/PowerPC-port-for-company-tp7578410p7578416.html

Sent from the eLua Development mailing list archive at Nabble.com.
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev



--
James Snyder
ph: <a href="tel:%28847%29%20448-0386" value="+18474480386" target="_blank">(847) 448-0386

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev



--
Will Johnson
Cell: 1-616-808-1692

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Martin Guy Martin Guy
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC port for company

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