★ APPLICATIONS ★ PROGRAMMATION ★ LASER COMPILER|Amstrad Action) ★ |
| Laser Compiler | Applications Programmation |
The amazing Bertram Carrot reviews the latest Ocean/Oasis ottering. Can it speed up the poor man's miserably slow BASIC? Will Carrot become a top-notch machine code progger? For a long while now I've been working on Curse of the Android Lemmings, the latest Carrot megazap written entirely in BASIC and sporting one of the slowest gameplays known to mankind. So it was with much glee that I wrestled with the padded bag that arrived courtesy of Securicor a couple of days before this issue went to press. Just the job, I thought, to put some perzaz into the robot rodents. The Laser Compiler is the latest in a line of programming aids for those who can't or won't 'get their hands dirty' with a bit of Z80 machine code. Laser BASIC, reviewed in February's Amstrad Action, does a lot for those who believe that POP IY is a funny spelling of Olive Oil's boyfriend. It provides all kinds of wizzo sprites for use in your own games, and machine-code routines to manipulate them. Laser Compiler tackles the bits of program not directly concerned with putting lemmings on the screen;the calculation and program logic involved in a good game. When you've compiled a BASIC program with Laser, you'll notice a significant speed improvement, not in the sprites themselves, but in the way the program works out what to do next. Two sample programs are included in the manual; the notorious Sieve of Eratosthenes, invented by an ancient Greek to show off the speed of his BASIC compiler, and a routine to draw a circle. If you run these two programs under Amstrad BASIC against their Laser compiled equivalents, you'll see a speed improvement of 20 to 30 times for the Sieve and about 3 times for the circle plot. Well worth having, but what sacrifices do you have to make? Well, for a start, you can't use any floating-point numbers. Not as much of a problem as you might think, especially when writing games, as nearly everything is done with integers anyway. It does mean that the RND function (which normally returns a number between 0 and 1) has to be rewritten, and any programs you want to compile will need to be adjusted accordingly. There are some restrictions on the use of MEMORY, and immediate mode commands, such as AUTO, RENUM and NEW, are not supported. Nothing that should really worry you, though. Syntax checking What is a bit more worrying is the 'fussy' syntax checking. If you write 'IF INKEY(32) THEN GOSUB 1000' in a program, you'll have to alter the line to read 'IF INKEY(32) < > 0 THEN... before Laser will accept it. It won't accept the Pascal-style square brackets around array elements e.g. DIM Array$[20], although Amstrad BASIC does, and was none to happy with the statement 'IF caught THEN RETURN'. It demands a full Boolean expression (e.g. caught = 1) to compile. The manual gives details of which keywords aren't supported, and lists the error messages the compiler may produce. It would have been useful to have had some of these explained, and there were a couple the compiler produced which weren't listed, including the unhelpful 'RUNTIME ERROR-UNKNOWN ERROR. PROGRAM TERMINATED'. Considering how well Laser BASIC is documented, I think Laser Compiler deserves more than 15 pages. The compiler The compiler is generally well behaved, and will take your source BASIC, whifch should be thoroughly debugged, and compile it in two passes. The first pass checks the syntax, and reports errors, showing where in the offending line the problem lies. The second pass generates the machine-code. adding in the Laser run-time code to produce a stand-alone program. This code is quite lengthy, around the 10K mark, and is longer if your program includes Laser BASIC sprites. Using Laser Compiler is the only way to create a program with sprites which will run without Laser BASIC being present. The final product is run only, and as such may be sold by you, without further permission from, or payment to Ocean. A very realistic approach. Compilation of a typical 10K program takes about three minutes, including disc swaps. You can rim the compiler from tape, but it's awkward.
Test programs And so to C.O.A.L., or at least the programs I tried it on before trusting it with the game which combats insomnia. I have to admit at this stage that in the time available for the review, I only managed to get one out of three test programs compiled and running under Laser. The first was a simple database, which reserves MEMORY for a couple of machine-code sub-routines. Laser rejected the use of HIMEM in the program, and a small rewrite would be necessary to put the code into memory in some other way. The second was a published BASIC listing for a game. Laser compiled the program without problem, but when run the 'UNKNOWN ERROR' described above, crashed my 6128. The third program was another mag listing, and after quite a bit of rewriting, Laser compiled this to machine-code over twice as long as the original. Although this compiled program ran all right (and a good bit faster than the original), part of the screen display was corrupted. The interpreted version had no such problems, and it's hard to see what could be causing them. Even with these problems, it's not fair to conclude that Laser won't compile fairly standard BASIC programs. If you were writing your program for compilation, you'd make sure you stuck to the syntax it could understand. Using Laser BASIC would also encourage this, as the routines provided there are all compatible with the Laser Compiler. All in all, Ocean's two programming aids will work together to provide much of the sophistication normally found only in games written entirely in machine-code. The extra memory overhead of a compiled program should not be too much problem, bearing in mind the program space available in Amstrad micros. Now, you see, these giant lemmings keep throwing themselves of the cliff and your job is to catch them in your wellies ....
GOOD NEWS BAD NEWS ? Adds considerably to length of programs.
|
