How to embed MicroPython in multiplatform C++ framework

[p-i-]

I confess to not knowing what I'm talking about but isn't standard Python set up already to allow embedding?

https://docs.python.org/2/extending/embedding.html

Andrew

There is no easy way to get multiplatform though. You would require linking against the libpython.a library, and you would need a different version of this library for each targeted platform. It's doable, but messy.

With the approach I'm currently looking at, it should be possible to get all targeted platforms without using any libraries.

π

[stijn]

How would one go about implementing uPy from scratch on a new platform?

Try to compile with the current makefile for the platform closest to the new one. Fix errors, committing each change you make with proper commit messages so that afterwards you and reviewers still can follow everything. If there's only a couple of minor changes, say when using the current unix port to get it to compile for iOS, you don't need a spereate platform directory I'd say. When done, create pull request. There's really no other way I think..

PS I am still struggling to see where platform dependency enters -- I would imagine a Python interpreter to be pure C, unless it is making external library calls, like "send data over UDP" etc. Maybe different platforms having different variable types, like 16 vs 32 bit integers. But that would just be a case of a preprocessor macro saying something along the lines of: #if plat==PLAT_OSX typedef upy_uint UInt32_t

The latter is exactly what is done in mpconfigport.h for the different platforms. That also enables/disables specific functionality. So yes the interpreter is pure C99, and the platform directories mostly add I/O functionality etc. So if you disable pretty much everything (like bare-arm) does there aren't much platform specifics.

[dhylands]

Well almost pure C99.

Having looked at this recently, you can do it with pure C99 (so far, mips is the only platform which does this). All of the rest use some assembler since the nlr_ stuff written is assembler is more efficient than what setjmp does. This is because setjmp has to save ALL of the registers, whereas nlr doesn't, so the assembler stuff is more efficient, but the setjmp is more portable. Take your pick.

[nande]

That would be awesome!
I tried making a game engine programable with python (much like panda3d) and i've managed to port it to unix, windows and blackberry 10 , but that's because i already knew how to compile python for those platforms.. but its really messy and complicated..
im actually making a game (http://appworld.blackberry.com/webstore ... US&lang=en) in cocos2dx (c++ game 'engine') and its portable to blackberry 10, playbook, android, unix, win, mac. which are all important to me but we can't port python for all of them.

upy seems more portable. it's far lightweight and faster. i would REALLY could use it to run some basic scripts, it could make our development far easier.
i've seen the wrapper for stij, too bad it seems to use c++>99 (ive seen some auto's there).
some platforms only support c++99, like some old androids and blackberry.

[stijn]

ive seen some auto's there

yes, it would be much messier than it is now without autos; but the main reason for C++11 is the use of variadic templates (and less important rvalue references). Without it you'd have to resort to super ugly and impossible to debug macro implementations, or provide overloads until the maximum number of arguments you'd want to support. And again some more overloads for conversion of std::tuple/std::function, etc.

That being said, the wrapper is only to make it less cumbersome to make C/C++ code callable from uPy and it goes pretty far in that. You can achieve similar functionality in C++99 with just a couple of utility functions. Also if you don't have a lot of code and don't mind copy-pasting some of the boilerplate code you don't need much utility at all and can use uPy as your scripting language with a minimum of effort. Especially since you seem to have it already for CPython it shouldn't be that much work.