Author Topic: PyMite 68k  (Read 2145 times)

0 Members and 1 Guest are viewing this topic.

Offline TC01

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 344
  • Rating: +9/-0
    • View Profile
PyMite 68k
« on: July 06, 2011, 04:08:24 pm »
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. :P

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:

Quote
•Requires roughly 55 KB program memory
•Initializes in 4KB RAM; print "hello world" needs 5KB; 8KB is the minimum recommended RAM.
•Supports integers, floats, tuples, lists, dicts, functions, modules, classes, generators, decorators and closures
•Supports 25 of 29 keywords and 89 of 112 bytecodes from Python 2.6
•Can run multiple stackless green threads (round-robin)
•Has a mark-sweep garbage collector
•Has a hosted interactive prompt for live coding
•Licensed under the GNU GPL ver. 2

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.



The userbars in my sig are links embedded links.

And in addition to calculator (and Python!) stuff, I mod Civilization 4 (frequently with Python).

Offline Lionel Debroux

  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2135
  • Rating: +290/-45
    • View Profile
    • TI-Chess Team
Re: PyMite 68k
« Reply #1 on: July 06, 2011, 04:42:48 pm »
Looks like we've had the same idea :)
I'm currently working on it, but I silently did so until this post, because:
Quote
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.
(emphasis mine) Getting p14p to compile on GCC4TI is the main problem. p14p requires improvements in both the toolchain and the library, to make them somewhat less non-standard and more flexible. And even then, some wrestling with the toolchain's peculiarities, in the Makefile, is required...

I do have a partial (without UART support, so no interactive module) port in perfectly working shape, it can do significantly more than print("Hello World !"). But it can't be easily released before the next beta of GCC4TI, because of the toolchain and library changes, and the fact that compiling GCC4TI from SVN isn't easier than compiling TIGCC from CVS...
In GCC4TI, we've worked on the user scripts (aborting upon error instead of silently finishing incomplete builds, large portability improvements, etc.) but not much on the maintainer scripts. In the longer term (i.e. not a target for the next GCC4TI beta), that set of ad-hoc build scripts inherited from TIGCC ought to be replaced with something better...


While I'm at it: I'm also working on the "kernel"-based Lua port for the 89 I recently found about in a discussion on yAronet, and linked in another topic on Omnimaga. I've cleaned up the patch, it will need forward-porting from the old Lua 5.0.2 to newer versions.
I need to make conditional the reimplementation of strtod contained in the original patch: I recently added strtod to GCC4TI (I knew since 2002 or 2003 that AMS contained a strtod, and I notified the TIGCC maintainers, but nothing happened...), but I'm not sure that PedroM has it at all, or has it wired on ROM_CALL_4D4.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TILP and TIEmu.
Co-admin of TI-Planet.

Offline TC01

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 344
  • Rating: +9/-0
    • View Profile
Re: PyMite 68k
« Reply #2 on: July 06, 2011, 04:59:41 pm »
Oh, nice! You might also want to crosspost this to the Cemetech thread I started.

So when is the next beta of GCC4TI going to be released?

I guess I can move onto some other project now. :P



The userbars in my sig are links embedded links.

And in addition to calculator (and Python!) stuff, I mod Civilization 4 (frequently with Python).

Offline Munchor

  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6200
  • Rating: +295/-121
  • Code Recycler
    • View Profile
Re: PyMite 68k
« Reply #3 on: July 06, 2011, 05:08:47 pm »
This is a great idea, I've always wanted on-calc Python, I hope you can make it succeed :D

EDIT: I now read the whole topic and see it's impossible, but I hope that eventually it will work :)
« Last Edit: July 06, 2011, 05:09:28 pm by ephan »

Offline TC01

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 344
  • Rating: +9/-0
    • View Profile
Re: PyMite 68k
« Reply #4 on: July 06, 2011, 05:15:38 pm »
This is a great idea, I've always wanted on-calc Python, I hope you can make it succeed :D

EDIT: I now read the whole topic and see it's impossible, but I hope that eventually it will work :)

Impossible? It's not possible on most z80 calcs, yeah, but it's possible on the 68ks: once the next beta of GCC4TI comes out anyway.

And that means it's definitely possible on Nspires.



The userbars in my sig are links embedded links.

And in addition to calculator (and Python!) stuff, I mod Civilization 4 (frequently with Python).

Offline Lionel Debroux

  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2135
  • Rating: +290/-45
    • View Profile
    • TI-Chess Team
Re: PyMite 68k
« Reply #5 on: July 07, 2011, 06:49:43 am »
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).

EDIT July 10th: publishing the patch, which I refreshed today but hasn't changed since July 2nd: http://www.mirari.fr/V6V4
« Last Edit: July 10, 2011, 12:48:28 pm by Lionel Debroux »
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TILP and TIEmu.
Co-admin of TI-Planet.

Offline TravisE

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 162
  • Rating: +33/-0
    • View Profile
    • ticalc.org
Re: PyMite 68k
« Reply #6 on: September 10, 2011, 05:40:48 pm »
In my tests, p14p and Lua89 have proved to be fairly slow:
* p14p: recursive Fibonacci with parameter 12 takes hundreds of milliseconds;

That's still a lot faster than TI-BASIC, which takes up to tens of thousands of milliseconds. ;)
ticalc.org staff member—http://www.ticalc.org/

Offline Lionel Debroux

  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2135
  • Rating: +290/-45
    • View Profile
    • TI-Chess Team
Re: PyMite 68k
« Reply #7 on: September 11, 2011, 01:34:54 am »
Indeed, that's much better than TI-BASIC, which I didn't even try to test :D
But it's still too slow for serious computations and for Lua on the TI-68k platform becoming more than a proof of concept...
« Last Edit: September 11, 2011, 01:35:03 am by Lionel Debroux »
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TILP and TIEmu.
Co-admin of TI-Planet.