By Jewe | April 15, 2015
About the challenge to run on small machines.
Recently, I came across Vincent Rivière’s m68k-atari-mint cross tools. It’s a port of the GNU compiler collection (GCC 4.6.4) to allow cross-platform compilation for the Atari ST under Windows. The compiler is able to target executables for MiNT / FreeMiNT and the plain old TOS / GEM operating system.
Of course, having a long history of programming the Atari ST myself, I felt compelled to try to port JewelScript to the Atari. If only to see how far I’d come.
Remarkably, there was no actual ‘porting’ to do at all. Since JewelScript’s code is ANSI C and fully GCC compliant, the runtime environment and demo application just worked. I was in awe at that.
I don’t deserve the credit for this though. The credit for making this so simple and easy entirely goes to Vincent Rivière, who put a lot of hard research and work into providing a cross-platform compiler suite for the Atari ST.
For the most part, doing this was just for fun. However, I do see an actual purpose in this. Being able to run something written on a much faster machine on a very slow one can show you the bottlenecks in your software design. In a way, running JewelScript on the Atari ST is like test driving the software on a profiler.
Having a running prototype on the Atari ST is also proof that the software is actually capable of running on machines with limited resources, such as System-on-a-Chips or Micro-Controller boards.
So now there’s a new programming language available for the Atari ST / TT / Falcon platform, featuring most of the programming semantics of modern object-oriented languages like Java and C#. Of course, to be actually useful, the runtime environment would require an extensive library of native classes. If GEM functions were available as native classes, you could even write GEM applications in JewelScript.
To be completely honest, I do not recommend using JewelScript on a real Atari ST or a machine that is comparably slow. The highly object-oriented design of the compiler works well on modern machines, but not so much on old or slow hardware. Luckily, you can save and load compiled scripts as binary files. Being able to compile scripts only once and then load them from binary files can make a real difference on slow machines.
The performance of the compiler becomes acceptable with machines that are capable of speeds of 32 MIPS or higher (that would be a 128 MHz Atari ST). Since Micro-Controller boards with 80 MIPS or more are no rarity these days, I’d say that there’s a good chance JewelScript would perform well on those.
Comments are closed.