Last month we looked at five well-established Spectrum compilers — programs to translate ZX BASIC into fast machine code. We left you excitedly waiting for the results of our tests on two new compilers Colt and BLAST. At the last moment, we received a copy of Mcoder 3, another BASIC compiler scheduled for imminent launch. Do the new programs knock spots off the golden oldies? Read on to find out...
£12.95 from HiSoft
The Colt is a new BASIC compiler from HiSoft, previously well-known for their Spectrum Pascal package. Colt is a fourth generation program, descended from ZX-GT, Mcoder 1, and Mcoder 2, reviewed last issue. Rather confusingly, Mcoder 3 (which we look at later) is an entirely new program.
Colt is more than just a BASIC compiler — the package also contains The Executive, which contains a number of useful extensions to BASIC, some of them quite unusual and others rather dull. You get a digital clock accurate to a tenth of a second (!), which you have to set using just two keys, like a tatty radio alarm. You can control the clock like a stopwatch, but it stops whenever you use cassettes or microdrives!
You get single-key commands, some of them programmable, but these use the Space key as an extra Shift. This interferes with key ‘roll-over’, so you have to be careful when typing text, or Space characters get lost. Command entry takes a lot of getting used to — you must press Space, then another key, then release Space, then release the other key. If we hadn’t got used to Spectrum single-key entry, we’d say it was almost unusable...
The Executive offers a full set of QL-style windowing commands and a sprite handler which can cope with up to 16 large sprites (32 by 24 pixels). These facilities allow smooth movement and scrolling, with automatic collision detection. Keen programmers may value commands for error-trapping, logging the parts of a program which take the most time, deleting groups of lines and base conversions — in the unlikely event that they haven’t already got programs to do such things.
Colt itself occupies about 6K of memory, and The Executive requires another 7K. You can use the compiler on its own if you wish. Even this may not leave enough space to compile large programs, since Colt normally keeps the original ‘source’ and the compiled code together in memory. You can compile up to about 16K this way; otherwise you must tell Colt to overwrite the original program as it compiles it, allowing up to 32K to be compiled, but forcing you to save and load your program every time a change is needed.
Colt works blindingly fast, churning out code at a rate of about 1K a second! This makes it noticeably faster than Mcoder 2 and the Softek compilers, and MUCH faster than all the others. If an error is found the line is listed with a flashing question mark, and the cursor is set so that the line pops up as soon as you press EDIT. In view of the speed of compilation, it hardly matters that Colt only finds one error at a time!
Unlike the other compilers reviewed this month, Colt is an integer-only compiler, which means that arithmetic is done using whole numbers, trading accuracy for speed. If you are writing a new game the lack of floating point arithmetic should not cause many problems, but it does make it very unlikely that you will be able to compile existing BASIC programs without major changes.
Colt recognises the vast majority of ZX BASIC commands, although user-defined functions and arrays of more than one dimension are prohibited. Calculations are not allowed in DATA statements, and there are minor limitations on the use of AND, OR, LEN, CLEAR, RND and FOR.
The benchmark timings show that Colt produces much faster code than BLAST or Mcoder 3. Programs compiled with Colt run at roughly the same speed as those processed by Mcoder 2 or Softek’s IS compiler; only ZIP produces substantially faster code.
You can use commands from the Executive in compiled programs — window and sprite-handling is likely to be especially useful. Colt is the only fast compiler which recognises microdrive commands, and HiSoft claim that it can even cope with floppy disks and wafer drives so long as they use the Sinclair keywords. Of course, the compiler doesn’t actually speed-up these operations — it just calls the ROM like normal BASIC.
There is a ‘trick’ way of doing floating-point
arithmetic in programs compiled using Colt. If the VAL, VAL$ or STR$
functions appear in a compiled program, the interpreter is used to work out the
result, so decimal maths can be used inside the string being processed. You can
in a compiled program; the calculation is performed using full floating-point maths (at the speed of normal ZX BASIC) and then NUM is set to the whole number part of the result. If you use:
LET ST$=STR$ VAL("7/2")
the string ST$ is set to ‘3.5’, the correct floating point result, although there’s not much you can do with it except PRINT it or use it in another VAL expression.
This would be a powerful feature but for the fact that any variable-names in VAL strings refer to BASIC variables, rather than to the variables in the compiled program. It is a useful way of passing values from BASIC to machine code, but it is often just a source of irritation, as there is no way a compiled program can set BASIC variables. You can read Colt variables from BASIC, but that’s not quite the same thing...
We looked at the pre-release version of the compiler, so the documentation was not in its final form. What we received was plentiful and interesting, although much of it might be heavy going for someone unfamiliar with the intricacies of machine code and the Spectrum ROM.
The Colt package is good value at £12.95, but it is not very easy to use — it is rather idiosyncratic, like all the integer compilers, and various tricks and POKEs are needed to get the best from it. Colt is recommended to hardened hackers, especially if the Executive facilities fill a gap in their present armoury.
£24.95 from Oxford Computer Systems (Software)
BLAST is the compiler that everyone has been waiting for, since the first advertisements appeared back in May. Billed as ‘the first fully compatible optimising BASIC compiler’, capable of compiling ‘ANY BASIC PROGRAM, without alteration’ into ‘super efficient code capable of running at up to forty times the speed of BASIC’. Other advertised goodies included ‘many extensions’, ‘genuine integer variables’, ‘debugging facilities’, and ‘a comprehensive toolkit’.
With a billing like that, we couldn’t wait to get our hands on ‘the complete BASIC programmer’s package’. Sadly, the reality was rather different from the hype.
BLAST is supplied in a large plastic box, about the size of two Betamax video cassettes. Inside the box is a 30 page typeset handbook, of roughly A5 size. Three sides of corrections, on separate sheets, convey the first disappointment — the ‘MANY EXTENSIONS’ touted on the lid, have not been implemented ‘due to lack of memory’. As compensation, some extra features have been added to the toolkit.
The manual’s content — once you’ve made the corrections and crossed out the pages which are now irrelevant — is quite interesting. Unfortunately there are no examples and the organisation is poor; the manual skips back and forth between subjects and contains several irritating forward references. The spelling and grammar are erratic.
The box also contains a ‘protection’ grid, which you are asked to refer to whenever the compiler is loaded — it contains about a thousand coloured dots. You have to identify four of them to prove that you have good eyesight and a legitimate copy of BLAST. If you make a mistake, the program crashes and you have to reload all 48K from scratch.
The other side of the tape contains the BLAST toolkit, which offers all the usual facilities — trace, search, copy, renumber, delete, list variables and so on. As with Colt, many BASIC programmers will already own such utilities.
There were signs that the toolkit had been thrown together in rather a rush — it was possible to crash the machine by careless use of Search and Replace, for instance. The special ‘BLAST save’ option, which writes files in small sections so that they can be read piecemeal by the compiler, does not check its parameters until after it has printed the START TAPE prompt, giving a jumbled display. There is no wait for a key press before saving begins.
The BLAST renumber command can’t cope with more than 643 lines, unlike other toolkits. Most annoying is the fact that search and replace does not cope with the ‘hidden numbers’ in all Spectrum programs. ZX BASIC keeps the binary form of numbers stored after the text, though you can’t see it when you type LIST. BLAST can’t see it either, so an attempt to replace one number with another changes the text but not the value — you see the new value when you type LIST, and the old one when you run your program!
BLAST generates two types of code — machine code, which is fast but verbose, and p-code — symbolic code which is concise but runs more slowly. There is just 2½K free once the compiler has been loaded, so you can only compile tiny programs without recourse to tape or microdrive. The toolkit is 5K long (the manual says 2K), so you can’t load it at the same time as the compiler.
We tested BLAST with the eight standard benchmark programs. The machine code timings obtained are shown in the benchmark table. BLAST code is slightly faster than that from Softek’s FP compiler, substantially slower than that from Mcoder 3, the other ‘full’ compiler, and much slower than the integer-only compilers. These results were a little surprising — an ‘optimising’ compiler ought to be able to make mincemeat out of the benchmarks.
We tried using the p-code instead of machine code, and found that the results were up to twenty percent slower than when machine code output was selected. The big shock came when we specified that some variables were to be treated as integers — it made no difference at all!
Without this option, it is hard to believe that the promised speed up of 40 times could be achieved in real programs. An Oxford employee admitted on the ’phone that the optimisations advertised and documented in the manual were missing. We were promised a succession of upgrades, but none arrived after several weeks and repeated requests.
BLAST’s user-interface is good, with no need of the RAND USR calls of the compilers reviewed last month. To compile a program you type one two-character command; to run it you type another. As programs are compiled, the screen memory is used as a temporary storage area, producing a riot of flashing dots and cascading colours, which helped to pass the time during compilations, which took place at a rate of a couple of lines per second. As a simple test of BLAST’s error-detection, we gave it a program containing a spurious NEXT statement. The error was not detected as the program was compiled; when we ran the code the value sixty million million was mysteriously printed and an ‘out of memory’ error occurred, with no indication of the type or location of the error. To be fair, we tried the same incorrect program on the other compilers. They coped rather better, either skipping the extra NEXT or rejecting it with a ‘NEXT without FOR’ message.
We then limbered up our microdrive, and prepared to compile some real programs. Our first attempt came to an end after about a minute and a half, when BLAST spat out the message ‘VARS TOO LONG’ and crashed as soon as a command was entered. We ’phoned Oxford to ask what this meant, but they wouldn’t say. Another upgraded copy of the compiler was promised, but, a fortnight later, it hasn’t turned up.
We tried the same thing again, and found a rather silly bug — BLAST crashes if the file which it is asked to write already exists. After re-loading, looking up the colours and so on, we checked that the compiler acted sensibly if the input file was missing. It didn’t — it crashed, again.
We tried another published BASIC game, which Mcoder 3 had compiled successfully. After 852 seconds (they said BLAST worked in ‘seconds’) the compiler stopped, complaining ‘SYSTEM ERROR 1’.
It was a relief to find a simple program (Spectrum Autosonics, published by Buttercraft way back in 1982) that BLAST was able to compile. Or at least, BLAST chugged all the way through the code and produced an output file. When we tried to run it, following the instructions to the letter, guess what?
The machine crashed.
We couldn’t find a single, nontrivial program that BLAST would compile.
In case you haven’t already got the drift, the performance of BLAST is pretty shocking; we wonder what those who have already paid £24.95 for a copy must think. The program seems to have been launched almost totally untested — the documentation and the advertising bear little relation to the product.
Not so much a BLAST, more of a Phut.
Mcoder 3 arrived shortly before this review was finished. It was first published in France last year, by an outfit called Ere Infomatique. Now PSS have bought UK rights and renamed it Mcoder 3, though it has nothing in common with earlier Mcoders. It is an interesting program, which operates quite differently from the others on the UK market.
We looked at a French copy of the compiler, with documentation to match — ‘Vous venez de transformer un program BASIC en language machine’, it chirps in fluent Franglais. The cassette cover features a wonderful picture of a circuit assembly being sucked through a funnel — I hope PSS use this on the UK version. They are working on an expanded English manual, but in fact Mcoder 3 doesn’t need much documentation, since it compiles just about all of ZX BASIC, with very few idiosyncracies.
Mcoder 3 is a full floating-point compiler, to be compared with BLAST and Softek’s (rather more restricting) FP program. The compilation process is more long-winded than Softek’s, as the compiler must be loaded — in two sections — every time a compilation is required. No instructions are provided on how to make a working copy, which is a mistake since the master tape is likely to get quite a thrashing; there is a spare copy on the other side of the cassette.
You can compile programs of up to about 25K with Mcoder 3. The snags are that you can’t compile from microdrive or tape (there is no support for Interface 1 commands) and you lose your original program as it is compiled.
The only restrictions from standard ZX BASIC are that arrays must have constant dimensions (rather than dimensions worked out by the program) and they can only be dimensioned once. MERGE and LIST are not allowed in compiled programs, since there’s no program text after compilation, and RUN and CLEAR reset variables to null or zero rather than forget them completely.
Before using Mcoder 3 you should load your BASIC as normal. Then type LOAD "" CODE and play the compiler cassette for about forty seconds. This loads the first part of the compiler, which checks for errors (reporting only one at a time, but leaving your BASIC in memory), deletes comments and generally tidies up before the real work begins. One nice feature is that REMs at the start of a program are retained, in case they contain machine code. Likewise DATA and DEF FN statements are kept in their original form, though they can be called from compiled programs.
A succession of messages flash up as the tidying process takes place — then the compiler prints PLAY and you can load the rest of Mcoder 3, which takes about 20 seconds. Mcoder 3 generates code at about the same rate as BLAST; it took a total of twelve minutes to compile a 16K program. As compilation takes place, the line number being analysed is displayed at the bottom of the screen.
When compilation is complete, you are left with a listing containing initial comments, DATA, function definitions and a single REM concealing the compiled code. You can start the program from any line with GO TO (so long as you have the original listing to hand); Break is allowed (unlike Softek’s FP compiler) and error messages even contain BASIC line numbers, you can print and alter variables used in compiled programs in the normal way, but CONTINUE doesn’t work (you have to use GO TO). RUN, DIM and CLEAR may corrupt the code if used after compilation.
The benchmark timings show that Mcoder 3 produces quite fast code — it gives substantially better results than BLAST and FP, and this is especially noticeable when ‘real’ programs are compiled.
The bad news is that Mcoder 3 seems to have a few bugs: INK RND*5 gave an error when run in compiled form, presumably because the compiler does not automatically round results to a whole number, as normal BASIC does. This snag was not hard to get around — we just added an INT statement in the line which Mcoder 3 indicated to be the source of the problem — but it is an incompatibility which should not be present.
We also had problems with strings getting corrupted as one compiled game ran. We discussed this by telephone with the publishers in France, but were were unable to work out a fix, or even diagnose the cause. Other string-handling programs worked fine.
Despite these flaws, Mcoder 3 is the only compiler we have looked at that has been able to compile ‘off the shelf’ programs with a reasonable degree of success. Softek’s FP compiler restricts the use of GO TO, GO SUB, arrays, functions and logical operators (AND and OR), and this meant that it would only cope with very straight-forward programs. BLAST was a waste of time.
It is surprising how well the old compilers have stood the test of time — perhaps this is because software houses underestimate the task of testing a compiler properly. ZIP still produces the fastest code at the lowest price, though it works slowly and lacks strings. Softek’s IS, and Mcoder 2 are still good value, although Colt provides a lot of extra features for three pounds more. Softek say that they will enhance FP to remove some of the restrictions (already VAL and VAL$ are allowed), but they’ll have their work cut out to catch up with Mcoder 3. BLAST can only be recommended to masochists. Serious games writers might do best by using a mixture of two compilers — one to handle the majority of the code, with a few restrictions, and an integer compiler to process high-speed sections. A discounted package offering IS and FP is in the offing, though users should bear in mind that Mcoder 2, IS, FP, and Colt are mutually incompatible since they all use the same memory to store run-time routines.
It is certainly possible to write hit games with a BASIC compiler — Virgin’s Sorcery and PSS’s Frank ’N Stein prove that — but there are still times when only machine code can deliver the goods. If you’re a hardened hacker, this may come as some relief!
The review of BLAST printed here used version 2.0 of the program, borrowed from CRASH Mail order. As we went to press, a review copy of BLAST version 3.0 arrived — and we had a quick look... The bugs that made the compiler we reviewed incapable of coping with non-trivial programs have been fixed, it seems. Some of the benchmark timings have improved, but BLAST 3.0 still produces consistently slower code than Mcoder 3.
It appears that the integer option still has no effect, and indeed there are no signs that the other advertised optimisations are taking place. We would warn potential purchasers of BLAST to make sure that the versions they buy are at least 3.0 or above.
With Version 3.0 there’s only 2K free for compiling in memory. We still can’t recommend BLAST to anyone without microdrives: as the manual says, ‘if you have large programs to compile and no microdrive we strongly advise that you get one...’
If you have already purchased an early copy of BLAST, Oxford Computer Systems will happily exchange your copy for version 3.0, their PR company tells us.
Eight standard BenchMark programs were used in the comparison: timings for the execution of each benchmark program are given in seconds, with the speedup ratios achieved by each of the compilers printed on a grey background.