64k tinypy – now with VM included
I’ve managed to build a simple VM into tinypy – modeled after the lua VM. It’s register based and “stackless” in the “it doesn’t use the C-stack” sense of the word. (Not in the, it does anything fancy like “stackless python” does sense.)
‘ve just reached the 64k mark, so that means anything I add into the code will require me to clean up other code to save space. I’ve already done a bit of that with good results. The one rule I follow in shortening code is that the code must retain readability, if not improve it.
Garbage collection is rather complicated, so I think I’ve decided to continue to leave that to libgc. I read some literature on the matter, and it sounds like I could write one, but it probably wouldn’t be very good. I’ve put it at the bottom of my TODO.txt list in the section labeled “Probably not going to happen”.
At present tinypy supports basic python code with functions and loops and lists and dicts and classes. At least, in some basic form. I’m looking towards adding in list comprehensions and *args **nargs to tinypy as those are two of my favorite python features. After that I’ve got a handful of functions I want to write and then some packaging work.
For the curious svn://www.imitationpickles.org/tinypy/trunk – ./run_julia_o3 to see it all happen. It depends on python to compile the bytecode (we’re not bootstrapped yet), libgc, and SDL.
January 10th, 2008 at 8:10 pm
Why not LLVM?
Not criticizing, because I admit I am far too stupid to make a meaningful positive criticism.
But why not?
(I thought LLVM would “feel” like old Apple II 6502 assembly language. From what I can figure out, not even close. I am having a hard time getting a feel for how LLVM works.)
January 10th, 2008 at 11:44 pm
Honestly, no “really good reason” other than I’m having a bit of fun ..
I am quite interested in the concept of keeping things small .. so I’m enjoying seeing how much I can get into 64k of code. LLVM (for example) is a 4.8MB compressed source download.
If I were being practical, I’d just break down and master SWIG or pyrex or the C–python API. In the meantime, however, it’s interesting learning how all the parts of a language work together. And keeping it at 64k makes it an easy to play with project. Once things get bigger than that, they start becoming “work”.
-Phil
January 10th, 2008 at 11:48 pm
… and with my interest in game development — this could (no promises) turn out to be actually useful.
January 11th, 2008 at 6:07 am
Hi Phil,
actually, being stackless in the “it doesn’t use the C-stack” sense of the word makes it rather easy to support cool Stackless Python features like tasklets or continuations. The hard work of Stackless Python was not using the C stack, not the actual user-exposed features. If you are concerned about size, just expose some very primitive stack switching and the rest can be done with libraries on top of that.
Fun project!
Carl Friedrich Bolz
January 11th, 2008 at 10:05 am
Carl,
Cool .. I’ve never actually used stackless, so I don’t actually use those features myself yet. But it’s nice to know that I’m “most of the way there” if I do want them 🙂
Phil
March 24th, 2009 at 8:52 am
It isn’t stackless, it just uses a separate C stack, à la setjmp()
March 24th, 2009 at 9:00 am
What am I thinking? Please ignore me..