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