[Stackless] cross compile stackless from x86 to mipsel

Jeff Senn senn at maya.com
Thu Feb 10 16:04:41 CET 2011

On Feb 10, 2011, at 9:43 AM, Christian Tismer wrote:

> On 2/10/11 4:02 AM, Jeff Senn wrote:
>> On Feb 9, 2011, at 9:27 PM, Christian Tismer wrote:
>>> And I'm wondering about the connection to openWRT ??? It is a quite
>>> different theme and I read a lot about it for my Buffalo router.
>>> What is the relation to Stackless?
>>> Although all this router stuff is great, I have very different thought here...
>>> Maybe we should chat a bit by private mails.
>>> cheers - chris
>> Chris-
>> I'm wondering if the thought you have is something like:
>> Since it's on an embedded platform with limited OS and perhaps
>> no C extensions, could we have a simple stackless that
>> *only* does soft-switching?
>> If so, I am interested in this thought since I have an embedded
>> platform where it would be interesting -- I've looked briefly at
>> it... only enough to realize that it's not trivial to get rid
>> of all the dependencies on stack switching given the current
>> organization of the code...
>> And if that wasn't your thought...
>> anyone care to think about it? :-)
> Hi Jeff,
> no, I actually meant OpenWRT, DD-WRT and others, which do a great
> job in the end. But I don't like the way they are implemented. Hard to
> maintain, arcane software technology. I would like to find the time
> and redo some of that. Writing a nice tool in Python that generates
> the code for a router, produces any GUI you like. I would go so far
> to provide the router with an API only and to write a PyQT application
> to access the router.
> But they squeeze it all in there, with some Javascript, with menus that
> work, but are not really flexible, are limited when it comes to more
> advanced stuff, and, most importantly, there are no good tests at all.
> I think there could be done so much better if they leave this C level
> coding by hand.
> But I think this is a common problem with lots of embedded
> software. They think it must be written in C, to become fast.
> This is in multiple ways very false.

Yep.  Interesting thoughts.

> ---
> 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...

> 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.

> 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 do you think?
> 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/

More information about the Stackless mailing list