[Stackless] cross compile stackless from x86 to mipsel

[Christian Tismer]

On 2/10/11 4:04 PM, Jeff Senn wrote:
> (chris)
>> On your simple stackless with soft-switching only:
>> Well, at first glance, we just need to disable the hard-switching part.
>> Would that what remains from Stackless then be enough for you?
> Yes. But I tried it quickly and it seemed non-obvious -- I didn't pursue
> very much, but it appears that the preparation in the code for later
> possible hard-switching, makes it difficult how to see to *simply*
> "disable the hard-switching part".  If it's more obvious to you please
> let me know - even if you say it might be easy, it may cause me to
> go look again...
>

Yes this is true. Actually the code started out with hard switching,
and grew the soft stuff later on. The possibility for soft-only is not
really considered. Maybe that is a useful addition to Stackless that
could be my task for the upcoming PyCon sprint?

I see the problem: The current design uses hard switching plus
some macros which consider soft switching, with no promise
that it will work. But switching is a promise.

That means, the only alternative is to raise an "unswitchable"
exception. But even that is not easy to find out before the actual
switch. It depends on the source and the target if it is ok.
>> Of course it could be interesting to have the complete Stackless
>> solution in PyPy (very doable) and then cross-compile for that
>> router thingie? But I'm not sure if that's the whole story, since PyPy
>> is quite huge. Where are the limits for your platform?
> PyPy feels too big... I really want a stripped down version and memory
> (and stack space!) are a concern.
>

Well, that depends. I read something about running PyPy on Maemo.
Have not looked into it, though.
I think the runtime memory of PyPy is no longer more than Python's.
But I have no clue if it is easy to strip it down enough concerning
the executable.
>> It would work without the JIT, and there is probably a problem with
>> generated code, anyway I guess? Then yeah, cross-compilation
>> of Stackless PyPy-c could be a solution.
> Executable code only in flash/ROM, so JIT/(dynamically) generated code
> don't help any...
>
> Consider: embedded processor, no OS, just one Python "scheduler" loading/
> scheduling "processes" written in Python.  Really a very minimal
> "pure Python OS".

What I think is possible is this:
With a little tweaking, it should be not too hard to add a tracing feature
to PyPy-c, that remembers all code paths taken.
You would create an exhaustive test case that touches every code
path taken. After that test has run, we could replace all dead code
by raising a NotImplemented exception.

Maybe the exhaustiveness of the trace can be reduced to the module
level. But I fear that has the side effect of pulling everything in.
Testing for certain data types would probably reference these types,
so I keep the idea of an exhaustive test.

With the test information on file, we start the compiler tool chain
and generate a new PyPy-c, but when writing the source code,
we replace all functions that are not logged by the trace
with that exception.

Maybe the approach is overkill? I'm at least pretty much interested
what this creates.

cheers - chris

-- 
Christian Tismer             :^)<mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key ->  http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/