So this is something I just started playing around with, and I thought I'd make a post about it mainly so it'd be easy to ask for help.

Python-on-a-Chip (formerly known as PyMite) is a Python interpreter designed for embedded systems. It supports a "significant subset" of the language. Here are it's features:



That sounds pretty decent for the 89, which has 256 KB of RAM and 188 KB of it user-accessible.

So theoretically, all I would have to do to make this run on a 68k is write some platform-specific routines for the 89 and get it to compile using GCC4TI.

That might be trickier than it sounds, though, because I'm not that great of a C programmer, and I'm not entirely sure yet how PyMite works. You need to use a Python script to convert your Python code into an image file of some sort, which then gets linked up to the C program... at least, I think it does.

I almost got it to build this morning, but it was complaining about the missing Python images- which I didn't even realize I needed until an hour ago. I haven't done any more on it yet.

EDIT: Lionel tells me that he has been working on this himself for some time, but has had to modify the GCC4TI toolchain and library to do it. As a result, he's not going to release it until the next beta of GCC4TI.

So I guess this thread is irrelevant then.

Omnimaga is currently giving me 404 errors when I'm trying to post. Fortunately, I had, as I often do when I'm posting long posts, saved the message I wanted to post (one hour worth of redaction - I've consistently been pretty slow, for ten years, at writing long technical posts) in my clipboard.
So let's post it here, and see whether Omnimaga is back after I have my breakfast


I have no precise ETA for the next beta of GCC4TI... Most of the things I'd have wanted to do for the next release have been done, but the server (Trac, SVN) has been used in read-only mode for months, after a hard drive problem, and godzil (owner of the server) doesn't have much free time.
Over the months, I've pushed a number of patches to https://github.com/debrouxl/gcc4ti (it's linked in the topic line of #GCC4TI, but not on the GCC4TI wiki, for the aforementioned reason). I need to push out several more patches I performed in the last few days - after more testing on some of them (strtod, snprintf, vsnprintf, etc.).
snprintf and vsnprintf haven't crashed on me in p14p, and they return the correct number of characters (because p14p does not print either truncated messages, or the ending 0x00) - but I haven't tested them in corner cases, e.g. length = 0, or aborting when vcbprintf would like to write more characters than the user has specified

Making a source tarball packing all those changes together would be rather easy - but it wouldn't help Windows users, who represent the majority of the user base. Windows users need a recompilation of the existing, modified tools, and a compilation of the new tools.


BTW, my motivation for the small-scale side projects of porting p14p to the TI-68k platform, and fiddling with the Lua port I recently found about, is an exercise in testing the non-standard toolchain and library against a wider range of real-world programs, and improving several bits as a result.
If you will, "I know fully well that the standards compliance of GCC4TILIB and GCC4TI is mild (though it's higher than that of TIGCC) - but how bad exactly is it for select real-world third-party programs, and is it easy to improve ?". I don't even speak Python or Lua

To me (others are free to disagree ), it's not an exercise in providing programs that would eventually prove highly useful to users:
* the TI-68k platform has always been much less widespread than the TI-Z80 platform, because its CAS forbade its usage in a number of standardized tests, and it was abandoned by TI six years ago;
* the TI-68k user and programmer base has been quite small for more than three years;
* most of all, there are better tools for programming TI-68k calculators in relatively fast high-level languages, starting with Newprog

In my tests, p14p and Lua89 have proved to be fairly slow:
* p14p: recursive Fibonacci with parameter 12 takes hundreds of milliseconds;
* startup time of Lua89 (5.0.2) is 2-3 seconds.

And it's pretty natural, I somewhat expected such kind of figures: the TI-68k platform is < 3 MIPS (12 MHz clock, all instructions take 4 clock cycles or more).
Lua is quite a good language for embedded platforms in general, but the only reason Lua is tolerable on the Nspire platform is that it's a > 100 MIPS platform (CPU can be clocked at more than 200 MHz, and instructions on ARM processors usually take 1 or 2 clock cycles).
Straight MIPS figure comparison isn't accurate (when dealing with memory, ARM often needs at least three instructions where the 68000 often needs one; this ARM flavour used in the Nspire doesn't have integer division), but the Nspire platform is, more or less, an order of magnitude faster than the TI-68k platform

One last note: the roadblocks in porting p14p, Lua or other similar real-world programs to the Nspire/Phoenix/Ndless platform are likely to be more in the library than in the toolchain itself (which is stock, unpatched GCC+binutils).