PicoC-remix -- an eLua distro

[raman]

Dear eLua community,

I trust you're all doing well. I have been caught up with university projects
and assignments -- hence the long silence. Nevertheless, I still keep up
with the evolution of the eLua code base. Bogdan: Great work on WOFS!
I simply love it.

I have something to share with you all. Although this is not related to the
development of eLua, it very much works on the eLua philosophy and
code base. Literally - eLua is a philosophy for me and Lua is a very apt
core for it. But out of curiosity, I started playing with eLua code base and
replaced Lua with what my friends wanted to see -- a C interpreter on
Cortex-M bare metal.

I looked around the internet and found the PicoC interpreter:
(http://code.google.com/p/picoc/). I put it together (after several modifications)
with the eLua base system. So now, I can write interactive C code on the
shell, run C programs from the MMC, read/run C programs from ROMFS --
basically, everything I would do with eLua but with PicoC instead.

So, now, from PicoC, I could avail all platform functions with #include's. For
example,

#include <adc.h>
#include <term.h>
#include <pio.h>
.....

I am yet to document the API but it mostly assumes eLua's format
for functions. For example, instead of pio.pin.setdir(pio.OUTPUT...) you
have pio_pin_setdir(OUTPUT...) (and similar for other platform modules
as well) in PicoC. Here OUTPUT is like a C macro and is stored in a rotable.

I also wrote a tiny (magic) RAM patch for this system. PicoC doesn't
have a garbage collector. So, for now, there is no way to query for
SRAM consumption at runtime (hence "magic"). You can tell the
difference between optram=0 and optram=1 only at build time.

Currently, the system can be compiled for the following platforms:
LM3S1968, LM3S8962, LM3S6965, LM3S6918, LM3S9B92,
STM32F103RE, STM32F103ZE and i386. This can be compiled
with scons. The standard eLua's scons syntax applies here too (with
exceptions to 'boot' (not supported yet) and 'target'). The stuff I haven't
yet included in PicoC-remix is in the TODO list.

Please look for the code base here: https://github.com/witgor/remix
A friend is maintaining it (https://github.com/witgor/)

Finally, I'd like to think of this system as an eLua distro :) -- a flavor
of eLua but with interpreted C instead.

I'd like your thoughts and suggestions on PicoC-remix. Please give me
a few tips on how to improvise on this.

Best,
Raman

PS: I really love the Mizar32 platform. I'd like to get PicoC-remix to run
on this. Unfortunately, I don't have the board with me yet but I'm going to
get one soon.

[Martin Guy]

On 16 September 2012 16:00, raman <[hidden email]> wrote:
> I looked around the internet and found the PicoC interpreter:
> (http://code.google.com/p/picoc/). I put it together (after several
> modifications)
> with the eLua base system. So now, I can write interactive C code on the
> shell, run C programs from the MMC, read/run C programs from ROMFS --
> basically, everything I would do with eLua but with PicoC instead.

Wow. Congratulations!

> I am yet to document the API but it mostly assumes eLua's format
> for functions. For example, instead of pio.pin.setdir(pio.OUTPUT...) you
> have pio_pin_setdir(OUTPUT...) (and similar for other platform modules
> as well) in PicoC. Here OUTPUT is like a C macro and is stored in a rotable.

You might prefer to use pio_OUTPUT to avoid name clashes - that way
everything pio-related is called pio_* and so on.  I'm sure there will
be two modules with the same macro names.

> I'd like your thoughts and suggestions on PicoC-remix. Please give me
> a few tips on how to improvise on this.

As most of the code is in common, a more maintainable strategy would
be to fork or branch eLua, create an extra directory src/picoc, hack
SConstruct to know which language it should include, then when you
have it able to build both systems from one source, merge the changes
back in. That would avoid having to maintain two sets of the same code
- assuming that the other modifications were not too invasive.

It's a tribute to the language-independence of the platform layer that
this was possibile to do!

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

[BogdanM]

Hi Raman,

Glad to hear back from you!

On Sun, Sep 16, 2012 at 5:00 PM, raman <[hidden email]> wrote:
>
> Dear eLua community,
>
> I trust you're all doing well. I have been caught up with university
> projects
> and assignments -- hence the long silence. Nevertheless, I still keep up
> with the evolution of the eLua code base. Bogdan: Great work on WOFS!
> I simply love it.

Thanks!

>
> I have something to share with you all. Although this is not related to the
> development of eLua, it very much works on the eLua philosophy and
> code base. Literally - eLua is a philosophy for me and Lua is a very apt
> core for it. But out of curiosity, I started playing with eLua code base and
> replaced Lua with what my friends wanted to see -- a C interpreter on
> Cortex-M bare metal.
>
> I looked around the internet and found the PicoC interpreter:
> (http://code.google.com/p/picoc/). I put it together (after several
> modifications)
> with the eLua base system. So now, I can write interactive C code on the
> shell, run C programs from the MMC, read/run C programs from ROMFS --
> basically, everything I would do with eLua but with PicoC instead.

You, my friend, are awesome. I already knew that, but this is insanely
awesome. Congratulations! I'm going to try this thing myself as soon
as possible. I'm really curious how it behaves in a limited memory
environment (I'm not worried about the compiled program, which would
obivously require less RAM than Lua code, I'm more concerned about the
compilation process itself). Plus, with us being able to manipulate
the code generation step much easier than you'd be able to do this
with GCC (whcih I imagine is the case), there are a lot of nick tricks
that one can perform, such as relocatable code (think loadable
modules), compile time support for debugging and so much more. I
simply love the concept.

>
> So, now, from PicoC, I could avail all platform functions with #include's.
> For
> example,
>
> #include <adc.h>
> #include <term.h>
> #include <pio.h>
> .....
>
> I am yet to document the API but it mostly assumes eLua's format
> for functions. For example, instead of pio.pin.setdir(pio.OUTPUT...) you
> have pio_pin_setdir(OUTPUT...) (and similar for other platform modules
> as well) in PicoC. Here OUTPUT is like a C macro and is stored in a rotable.
>
> I also wrote a tiny (magic) RAM patch for this system. PicoC doesn't
> have a garbage collector. So, for now, there is no way to query for
> SRAM consumption at runtime (hence "magic"). You can tell the
> difference between optram=0 and optram=1 only at build time.
>
> Currently, the system can be compiled for the following platforms:
> LM3S1968, LM3S8962, LM3S6965, LM3S6918, LM3S9B92,
> STM32F103RE, STM32F103ZE and i386. This can be compiled
> with scons. The standard eLua's scons syntax applies here too (with
> exceptions to 'boot' (not supported yet) and 'target'). The stuff I haven't
> yet included in PicoC-remix is in the TODO list.
>
> Please look for the code base here: https://github.com/witgor/remix
> A friend is maintaining it (https://github.com/witgor/)
>
> Finally, I'd like to think of this system as an eLua distro :) -- a flavor
> of eLua but with interpreted C instead.

I understand the concept, but I believe it is a bit more than that.
For quite a while now, people at PUC Rio have suggested that I should
split eLua into two parts: the platform interface part and the Lua
part. This would allow the platform interface to be used with other
projects too, which is exactly what you did here. I didn't embrace the
idea because I was mostly interested in pushing eLua as a whole, not
to maintain two separate projects, but what you did here convinced me
that their idea was right. This shouldn't be a flavour of eLua, but a
project with combines the "platform interface" (yet to be named as a
separate project) and your awesome (yes, I like this word) work with
PicoC. I'll take this into serious consideration and discuss it.

>
> I'd like your thoughts and suggestions on PicoC-remix. Please give me
> a few tips on how to improvise on this.

Make it even more awesome! :) And please let me know if you need help,
I'm really interested in this.
Once again, congratulations and keep up the good work.

Best,
Bogdan

>
> Best,
> Raman
>
> PS: I really love the Mizar32 platform. I'd like to get PicoC-remix to run
> on this. Unfortunately, I don't have the board with me yet but I'm going to
> get one soon.
>
>
>
> --
> View this message in context: http://elua-development.2368040.n2.nabble.com/PicoC-remix-an-eLua-distro-tp7577676.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

[raman]

>> with the eLua base system. So now, I can write interactive C code on the
>> shell, run C programs from the MMC, read/run C programs from ROMFS --
>> basically, everything I would do with eLua but with PicoC instead.

> Wow. Congratulations!

Thanks Martin!

>> I am yet to document the API but it mostly assumes eLua's format
>> for functions. For example, instead of pio.pin.setdir(pio.OUTPUT...) you
>> have pio_pin_setdir(OUTPUT...) (and similar for other platform modules
>> as well) in PicoC. Here OUTPUT is like a C macro and is stored in a rotable.

> You might prefer to use pio_OUTPUT to avoid name clashes - that way
> everything pio-related is called pio_* and so on.  I'm sure there will
> be two modules with the same macro names.

Certainly. I'll keep this in mind. I'll update this before I start on the
documentation.

>> I'd like your thoughts and suggestions on PicoC-remix. Please give me
>> a few tips on how to improvise on this.

> As most of the code is in common, a more maintainable strategy would
> be to fork or branch eLua, create an extra directory src/picoc, hack
> SConstruct to know which language it should include, then when you
> have it able to build both systems from one source, merge the changes
> back in. That would avoid having to maintain two sets of the same code
> - assuming that the other modifications were not too invasive.

This is a good point. I did think about this before. It would mean better
maintainability but this would also mean a profusion of conditional
compilation macros in the eLua code base. Is it worth it? Is there still any
other way to hold maintainability while keeping the two seperate? I could
still work on SConstruct and implement the switch in the languages if
it can be accomodated in the eLua code base. What are your thoughts on
this?

Best,
Raman

[raman]

Dear Bogdan,

>> (http://code.google.com/p/picoc/). I put it together (after several
>> modifications)
>> with the eLua base system. So now, I can write interactive C code on the
>> shell, run C programs from the MMC, read/run C programs from ROMFS --
>> basically, everything I would do with eLua but with PicoC instead. ...[show rest of quote]

> You, my friend, are awesome. I already knew that, but this is insanely
> awesome. Congratulations! I'm going to try this thing myself as soon
> as possible. I'm really curious how it behaves in a limited memory
> environment (I'm not worried about the compiled program, which would
> obivously require less RAM than Lua code, I'm more concerned about the
> compilation process itself).

Thank you! I had a lot of fun playing around with this. Please do give a shot
at it. Do let me know how it works.

> Plus, with us being able to manipulate
> the code generation step much easier than you'd be able to do this
> with GCC (whcih I imagine is the case), there are a lot of nick tricks
> that one can perform, such as relocatable code (think loadable
> modules), compile time support for debugging and so much more. I
> simply love the concept.

Bogdan, I'm sorry. I don't understand the part about GCC. Can you
please explain this to me a bit more?

>> Currently, the system can be compiled for the following platforms:
>> LM3S1968, LM3S8962, LM3S6965, LM3S6918, LM3S9B92,
>> STM32F103RE, STM32F103ZE and i386. This can be compiled
>> with scons. The standard eLua's scons syntax applies here too (with
>> exceptions to 'boot' (not supported yet) and 'target'). The stuff I haven't
>> yet included in PicoC-remix is in the TODO list.
>>
>> Please look for the code base here: https://github.com/witgor/remix
>> A friend is maintaining it (https://github.com/witgor/)
>>
>> Finally, I'd like to think of this system as an eLua distro :) -- a flavor
>> of eLua but with interpreted C instead. ...[show rest of quote]

> I understand the concept, but I believe it is a bit more than that.
> For quite a while now, people at PUC Rio have suggested that I should
> split eLua into two parts: the platform interface part and the Lua
> part. This would allow the platform interface to be used with other
> projects too, which is exactly what you did here. I didn't embrace the
> idea because I was mostly interested in pushing eLua as a whole, not
> to maintain two separate projects, but what you did here convinced me
> that their idea was right.

Great! I have also started working on another similar project. I wanted
to have a Lisp interpreter running on bare metal. I got the Pico dialect,
played around with it and finally linked it with parts of the platform
interface. (I haven't put up the code so far - It's going to take a while
before it's usable) I would be interested in doing this as well. For now,
the Lisp runs on my LM3S8962 (and i368). I can't do much with it apart
from (load ')-ing stuff from MMC :)

> This shouldn't be a flavour of eLua, but a
> project with combines the "platform interface" (yet to be named as a
> separate project) and your awesome (yes, I like this word) work with
> PicoC.

This would be a nice but as Martin said, how can things be done in a
maintainable way? What are your views on this?

> I'll take this into serious consideration and discuss it.

Can you please suggest how we can take this forward?

>>
>> I'd like your thoughts and suggestions on PicoC-remix. Please give me
>> a few tips on how to improvise on this.

> Make it even more awesome! :) And please let me know if you need help,
> I'm really interested in this.
> Once again, congratulations and keep up the good work.

Sure thing. Thank you Bogdan :) This has been a lot of fun.

Best,
Raman