VxWorks Port

[Paul Fernhout]

Darrin-

While I can't release the code (nor do I have it -- it was for a
client), I ported Python to VxWorks on the MIPS about a year ago. It
really didn't take more than a couple of days IIRC, although pretty much
all I needed was the core interpreter, nor did I do any complex
threading support (Mutexes, Queues, etc.) Doing that would take longer.
I was already familiar with the implementation of other byte coded and
semi-intepreted languages (Smalltalk, Lisp, Forth etc.) so your mileage
may vary. Also, it took quite a bit longer later to SWIG code I wanted
to link with the interpreter, so porting the interpreter is really just
part of the effort.

The reasons I used to justify it for the project wer:
* Being able to test code interactively.
* Being able to test code from scripts.
* Providing end user scripting.
* Allow some development to take place on a PC instead of the
development platform.

I think many of the configuration options I struggled with were related
to getting Python compiling under GCC for MIPS, not related to VxWorks
per se.  There were a few questions, all resolved more or less by trial
and error, staring with the Unix Port (don't try using the PC config
options under VxWorks -- I did the first time and they were very
confusing to start from).

One big set of issues was deciding for each type of functionality if
VxWorks/POSIX already supported it to avoid compile errors related to
redeclarations. I think once it compiled it worked (although it always
had some Python startup errors related to missing some desired
libraries...)

While I'm not sure this is the best approach, I created a directory
under the source for files I didn't think I needed (merging all the
files together from the various directories), and had a make file which
compiled what was in the current directory. Then I moved modules I
didn't think I needed out of the main source directory. I then just kept
recompiling and changing options till I got something that worked (maybe
making minor edits to a couple of files at some point).
The valuable part of the effort is really this list of minimal files to
include...

Since VxWorks supports so many platforms, it is going to be a somewhat
unique experience in any case.

I think the real arguements for Python under VxWorks is:
* testing
* time-to-market
* development on the PC
* open endedness

I think the size of the interpreter was around a few hundred K (300K?).
Many embedded systems these days have megabytes of memory.
Obviously, Forth is probably a better choice for an 68HC11 with 64K of
memory.

I never tried the advice on making a really tiny Python interpreter -- a
few hundred K was fine for this project. But I'd love to see such
configuration options as part of the standard distribution.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Jeff Collins wrote:
> 
> I don't know about VxWorks, but I have ported python to Brightstar
> Engineering's PPC-823 based embedded platform.  The port was fairly
> straightforward for both of their supported operating systems: the
> POSIX-compliant RTOS (called "pkernel") Linux.
> 
> During my (unreleased) port of Python-1.5.1 to the palm, I was able to
> significantly reduce the size of the code itself - down to approx
> 160K.  That's still quite large by palm standards, but small by python
> standards.  As the port of 1.5.2/1.6 continues, I'm finding ways to
> reduce the size of the source (then will examine the memory model to
> find ways of reducing the use of the heap).  This will hopefully
> benefit all embedded applications.
> 
> Jeff
> 
> Darrin Edelman writes:
>  > Hello all,
>  >
>  > I have seen a couple of posts and mentions of porting Python to VxWorks.  I
>  > am wondering if anyone can point me toward one of these ports or give me
>  > more information.
>  >
>  > As a side note, I am wondering how large the interpreter is -- is it really
>  > reasonable to put it into an embedded environment?
>  >
>  > Thanks in advance,
>  > -Darrin
>  >
>  >
>  > --
>  > http://www.python.org/mailman/listinfo/python-list
>  >