Shop OBEX P1 Docs P2 Docs Learn Events
micro python — Parallax Forums

micro python

ReinhardReinhard Posts: 489
edited 2014-06-20 05:35 in Propeller 1
A few days ago, I found this:
http://micropython.org/
It's a python implementation running on bare arm without an OS between.
First I checked out the micro-python-master.zip.
With the included Makefile I build micropython demo for unix like OS.
Works well on my linuxbox.
Then I disable the asm - parts, remove the dependence for libreadline,libffi and libdl, rebuild and it's work.
size ~ 300kB, with GC !
Next I try to port with propgcc, in the first step without filesystem, but in REPL mode.
( REPL means read-evaluate-print-loop, using stdin/stdout )
This could demonstrate the ANSI compatibility ;-)
Reinhard

Comments

  • ReinhardReinhard Posts: 489
    edited 2014-06-17 08:35
    hmm, alloca.h is missing

    The alloca() function allocates size bytes of space in the stack
    frame of the caller. This temporary space is automatically freed
    when the function that called alloca() returns to its caller.

    This function is not in POSIX.1-2001, but nice to have ;-))

    Reinhard
  • jazzedjazzed Posts: 11,803
    edited 2014-06-17 09:14
    PropellerGCC doesn't support POSIX or hosted mode.

    It meets the requirements for free-standing ANSI C.

    If you provide an implementation of alloca(), we can include it.
  • Heater.Heater. Posts: 21,230
    edited 2014-06-17 09:53
    Reinhard,

    I suspect you don't need to have an alloca() function and it would be better all around if MicroPython did not use it.

    In the C99 standard we have variable length arrays. So wherever you see something like:

    char *arr=alloca(size);

    just change it to:

    char arr[size];

    You will need to compile with -std=C99 or whatever the switch is.

    I hope there are not to many of these in the MicroPython code.

    Whilst we are here...this is great. Turns out that not only is there a Python than can be compiled to run on MCUs but also a JavaScript. Have a Google for "Espruino". Oddly both of those projects were started about the same time in Cambridge in England. Both of them had STM32 boards as Kickstarter projects at about the same time. Turns out the two guys involved had never heard of each other before launching their creations. What a coincidence.

    The earlier version of Espruino was TinyJS which has been running on the Propeller with external RAM. I was hoping to find time to get Espruino itself running as it is a much improved development.

    It would be great to have MicroPython and Espruino working on the Prop II with its copious RAM space. So good luck with your efforts.

    Hey, what do you know, this is my 10,000th post !!!
  • jazzedjazzed Posts: 11,803
    edited 2014-06-17 10:17
    Congrats Heater ;-)

    Glad to see you back.
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-06-17 10:32
    Happy 10,000th, Heater. !!!!

    An what a marvelous 10,000th it is!!!

    I've been playing with Espruino on the Olimexuino board (STM32 based that Espruino was targeted to early on) and look forward to microPython. I think a REPL on a micro is a really great development system and allowing interactive control of the hardware you are interfacing with instead of a compile/load/test cycle is a great advantage. It reminds me a lot of working with, well, you know, that OTHER language.
  • ReinhardReinhard Posts: 489
    edited 2014-06-17 10:52
    found a very old implementation, but works

    Reinhard
  • ReinhardReinhard Posts: 489
    edited 2014-06-17 12:41
    have improved the alloca test and for my understanding the behaviour is correct.
    Otherside I think about the comment from heater (happy 10.000;-) with the replace alloca(size) -> T [size].
    In any case I have fun with the prop;-)

    Reinhard
  • Heater.Heater. Posts: 21,230
    edited 2014-06-17 13:03
    Jazzed, mindrobots, Reinhard,


    Thanks for the congrats etc. It was nothing. I mean really, it was nothing. I'm not sure why one gets "VIP" status for gibbering a lot over a long time. Unless "VIP" means "Very Instant Poster" or some such:)


    Now, about that alloca. Damien George should be given a big hug for creating MicroPython and then a slap around the head for using alloca.


    Turns out that the code for alloca that Reinhard presented uses malloc anyway. That means that it introduces a lot of inefficient overhead. I cannot imagine anyway to do it that would be more efficient than using C99's variable length arrays. That standard is 15 years old already so I see no reason to stay away from it.
  • Heater.Heater. Posts: 21,230
    edited 2014-06-18 10:04
    mindrobots,
    I think a REPL on a micro is a really great development system and allowing interactive control of the hardware you are interfacing with instead of a compile/load/test cycle is a great advantage. It reminds me a lot of working with, well, you know, that OTHER language.
    Yes indeed. You mean Lisp of course. A very fine language:)

    I don't know about the Python REPL but the JavaScript REPL has this amazing property that you can set code running, say triggered by a setInterval(), and then continue in the REPL to add new code or modify the running code. Magic!
  • ersmithersmith Posts: 6,054
    edited 2014-06-18 13:44
    Reinhard wrote: »
    hmm, alloca.h is missing

    The alloca() function allocates size bytes of space in the stack
    frame of the caller. This temporary space is automatically freed
    when the function that called alloca() returns to its caller.

    This function is not in POSIX.1-2001, but nice to have ;-))

    Reinhard

    gcc has a built in alloc() function, called __builtin_alloca(). So just compiling with -Dalloca=__builtin_alloca should do the trick, or you can easily create an alloca.h that #defines alloca as __builtin_alloca().

    Micro Python sounds very interesting, it would be nice to have another language for the Prop :-).

    Regards,
    Eric
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-06-19 14:17
    Is anyone worried about the speed of this? I haven't used any of the prop's external memory models, but I thought they would be too slow considering the small on-chip RAM. Might it start thrashing?
  • Heater.Heater. Posts: 21,230
    edited 2014-06-20 05:35
    SwimDude0614
    Is anyone worried about the speed of this?
    It's going to me as slow as a drunken snail on the Propeller. It's an interpreter for one thing and it's going to have to work from external RAM for another. Are we "worried"? No, we are used to slow on the Propeller, we use Spin right?

    I managed to compile TinyJS the JavaScript interpreter for micro-controllers and somebody got it to run on their Propeller. I don't recall if any performance measurements were done. I imagine things are even worse there as JS only has one number type and it's 64 bit floating point!

    Still, these things have to be done. If you cannot see why it's better not to ask:)

    However, if it works on the Propeller it will work on the P2 when it arrives. Such things should easily fit in the P2's 512K memory and run at usable speed.
Sign In or Register to comment.