[Python-Dev] help for a noob - version for a sharp ARM

[David Boddie]

On Fri Dec 8 08:07:16 CET 2006, Josiah Carlson wrote:

> a Fred <fghaibach at comcast.net> wrote:
> > 
> > I'm looking for advice on stripping down Python for an SBC to run Numpy 
> > and Scipy.  I have the following notes on the system
> > 
> > We have code that requires recent versions of Numpy and Scipy.
> > The processor is a 32 bit Sharp ARM Sharp LH7A404 32 bit ARM922TDMI with 
> >      32MB of SDRAM.
> > 512 MB flash disk - but 400 MB is reserved for data
> > The OS is Linux 
> > only a tty interface is used.  
> > 
> > Does anyone have a feel as to whether Python for Arm is the correct 
> >      starting point?
> 
> Sounds like plenty of muscle to handle Python certain domain number
> crunching problems.

It appears that this ARM variant doesn't have a floating point coprocessor.

  http://www.sharpsma.com/Page.aspx/americas/en/part/LH7A404/

I hope we're dealing with those problem domains here. ;-)

> > What modules can I safely add/strip out?
> 
> Most every C module you don't need.  You can also compile without
> unicode.  I believe you can more or less toss everything except for the
> base python binary and the pythonxy.so (or pythonxy.dll) for your
> platform, but I am most likely wrong.

I found that Python tries to import various modules when it starts up, so
you might want to be a bit conservative with the ones you discard.
However, if the target platform doesn't have libraries that various extension
modules require then there's clearly no point in deploying those extensions.

There are lots of irrelevant modules (for your application, at least) in the
standard library. Anything that's platform-specific can go, apart from any
Linux-specific modules, obviously, and even those might be unnecessary. I'm
not sure if it's possible to automatically strip out Tkinter (lib-tk) and
IDLE (idlelib), but it's probably worth doing so in your case.

I should return to my own experiments and do all that again in a systematic
way, just to see what can be removed.

> My (awful) suggestion: start with 
> a Python installation in some user path, like ~/python .  Toss
> everything and start adding things that it complains about until it
> starts working again.

Or there's that approach. A module dependency graph would be useful to have,
or even just a list of modules that are required to get to the interactive
prompt.

It might also be worthwhile compiling all the pure Python modules to bytecode
and discarding the sources, but only if the compiled code is smaller, of
course.

> > Will Python take more than 5-6 seconds to load?
> 
> I have previously gotten dos versions of Python (I think 1.5 or 1.4) to
> load on a 486 sx 33 with 8 megs of ram in a couple seconds.  You
> shouldn't have issues with startup on an ARM.

Less than a second, I would imagine. Extension modules will also increase
the loading time, especially if they need to be perform some tasks when they
start.

> > Will old Python releases, like 1.5.x, work with newer Numpy and Scipy?
> 
> I don't know.  But you should be able to remove unused portions of
> Python for your platform.  There are somewhat recent posts in this
> mailing lists about embedded systems and Python.  Others may be able to
> help you more.

It should be possible to compile a version of Python for the ARM922TDMI
that uses Thumb instructions. These are 16 bit instructions that are expanded
on the fly so that they can be processed by the CPU as normal 32 bit wide
instructions. This doesn't mean that the resulting executable and libraries
will be half the size that they would have been when compiled normally, but
you may be able to save some storage space that way. I have no idea whether
this trick will help you save RAM as well.

David