Last month I looked at Ocean’s Laser BASIC — a set of graphics extensions to ZX BASIC — and mentioned the fact that a ‘compiler’ for the extended language was promised. The Laser BASIC Compiler has turned up, and it’s very, well, interesting.
For your £9.95 you get a crushproof plastic box, an eight page A5 manual, and one cassette. One side of the tape contains the compiler, ‘runtime routines’ and a loading program. On the other side there is a compiled copy of the Laser BASIC demonstration package. Curiously, many of the effects do not seem to to have been accelerated by the compiler, and some of the others are now noticeably more flickery.
The press release we received with the program says that the Laser Compiler will turn Laser BASIC into ‘fast machine code’. The packaging is less forthright, promising only that ‘compiled programs run typically twice as fast as their interpreted equivalents’. In the manual this is toned down still further to ‘probably only a factor of two or less’. You are allowed to sell compiled programs to anyone, and purchasers do not need the Laser BASIC interpreter.
The LASER Compiler is not easy to use. For a start, you are not allowed to load it while the main Laser BASIC system is in memory, so you have to save your program, reset the Spectrum, and re-load the BASIC before you can load the compiler. You also have to clear 6K of memory before you load the compiler, or it won’t work. The program really should do this for you.
Once the compiler is loaded you set it off with a RANDOMIZE USR command. The system overwrites your original BASIC as it works, and it ‘gives up’ as soon as an illegal command is found, spitting out an error message. You have to re-load your BASIC, correct the problem and try again for every single error, one by one. This is irritating even if you’ve got Microdrives — with cassettes it is mind-numbing, especially as not all of the error messages are listed in the manual.
Luckily, the Laser system doesn’t impose many restrictions. You’re not allowed to use calculated line-numbers in GOTOs, GOSUBs and RESTOREs, CLEAR is prohibited and array dimensioning works in a slightly different way — arrays are pre-built to a fixed size if possible. Microdrive data files are banned, but other Microdrive commands are allowed. There’s no program text after a compilation so LIST, MERGE etc, obviously don’t work.
The compilation process is very, very fast. Benchmarks compile in the blink of an eye and a 300 statement program was processed in under three seconds. I didn’t find any bugs in the resultant code, but — as we shall see — that is hardly surprising.
The code can be saved and loaded in the normal way, but the listing has disappeared, to be replaced by a dummy PRINT, a RANDOMIZE USR call, and a couple of lines containing all the DATA and DEF FN statements from the original program. The ‘compiled code’ is stored invisibly thereafter.
The tape-twiddling is not over once the program has been compiled. Believe it or not, you can’t use the compiled code when the compiler is loaded! You must first load the ‘run time’ routines that process Laser BASIC commands. These routines have to be loaded in place of the compiler.
This elaborate procedure meant that I was not able to perform all the usual benchmarks, but I did try a simple IF test. A loop that took 39 seconds in ZX BASIC ran in 28 seconds when compiled. This was a very disappointing result — much slower than any other Spectrum BASIC compiler.
I decided to try the Laser Compiler on a ‘real’ program — a game listing from a now-defunct magazine. The program was written in straight-forward BASIC, where it took, on average, 39 seconds to generate a maze. In ‘fast machine code’ — Ocean’s term, not mine — it took 35 seconds. In other words, the Laser Compiler made no useful difference to the speed of the program.
I tried a few other tests and they confirmed my impression. This ‘compiler’ was just making a few minor changes to the format of the program and ‘hiding’ the listing to make it look as if it had been compiled. I analysed a ‘compiled’ program file and discovered that it contained all the normal program text, keywords, variables and all — you could read the listing straight off the screen, and there was no sign of any machine code.
The re-ordering of data and definitions makes little difference to the speed of the code. The only other changes seemed to affect line-numbers and IF statements, where (I assume) addresses rather than numbers were used. This is not, in itself, a clever trick, since a program to do the job was listed in Your Computer magazine over a year or so ago. Beta BASIC does something similar when processing loops.
I can’t recommend the Laser BASIC ‘Compiler’ to anyone. It is expensive, hard to use and — in the final analysis — almost useless since it makes little difference to the speed of most BASIC programs. It is most short-sighted of Ocean to launch this program on their new ‘IQ’ label. It is not a compiler at all, in the usual computer-programming sense, because it uses the same tokens as slothful ZX BASIC. There’s no sign of the ‘fast machine code’ generation promised in Ocean’s press release.
The Laser ‘compiler’ may be useful to those who want to market programs written using the Laser BASIC interpreter, but I can’t believe that there will be many of them, and the package does seem to introduce extra graphics flicker. The run-time system should have been part of the Laser BASIC package to start with.