REVIEWS COURTESY OF ZXSR

HiSoft BASIC
by Andrew Pennell, Cameron Hayne
HiSoft
1986
Crash Issue 37, Feb 1987   page(s) 90,91,92

(Simon N Goodwin owns the copyright to this review. Please visit http://simon.mooli.org.uk to find original articles and updates, much new material and his contact details.)

THE ULTIMATE ZX BASIC COMPUTER

Most of this month's column deals with a new BASIC compiler from HISOFT, the utility publishers who have been responsible for a number of highly-respected products, including Devpac, the first 'professional' Spectrum assembler, and workmanklike compilers for the languages 'C' and Pascal'. The new product is called HISOFT BASIC, and is billed as 'a fast, floating-point compiler for the ZX Spectrum, 128 and Plus 2'.

We've always taken a special interest in BASIC compilers in TECH TIPS. In August and September 1985 we looked at eight packages that promised to turn slow BASIC into fast, efficient machine code. One of those - The Colt, now remaindered at £9.99 - was published by KSOFT, but that has not stopped the firm launching another compiler.

If 'compiler' is a new word to you, don't give up reading yet. A compiler is a programming tool that writes machine code for you. It can be used to write games, (indeed, any program) or just to 'soup-up' existing BASIC software. The 1984 rave from PSS, Frank'N'Stein, was written with a BASIC compiler. You don't have to be a programmer to use a compiler, but you do have to be vaguely interested in listings, gameplay or speed. The more interest you take in programming - at any level - the more useful a compiler will be.

FRIENDLY BASIC

Sinclair planned the Spectrum to be a machine for budding programmers, rather than for games players, so the built-in language is very 'friendly'. It lets you alter programs as you test them. It rejects lines that are 'obviously' incorrect, although it can't pick up all errors by looking at a line in isolation. You pay for this convenience, because ZX BASIC can make no assumptions. It checks every part of a program as it runs, in case a POKE has gone astray or you've changed something and re-started the program.

ZX BASIC is termed an 'interpreter' because of the way it works out everything it must do as it goes along. HISOFT BASIC is a 'compiler' - a program that runs once, to work out the exact meaning of a program. A compiler generates purpose-made machine code to do the same job - but with fewer checks and no time-wasting.

iCH BIN EIN Z80'r

An analogy may help to make the point. Imagine that you hire a worker who is very fast and efficient, but who can't speak your language. You're the boss - the program - and the clerk is the processor. Imagine that you've already got details of the clerk's task, written on a set of filing cards. The old clerk used to read through them, in sequence, and do the indicated jobs. If your new employee was to work like an iNTERPRETER he would take a dictionary and start looking up the works on the cards, one by one. When he's translated and checked a complete card, tied do the job - then he'd translate the next card, and so on. The worker can start almost at once, using the old cards you can read, but he is slowed by the need to translate every word every time.

Iit might be better to use the approach of a COMPILER. In this case you give the clerk a biro and a set of blank cards, and let him translate the instructions once and for all. You end up with a copy of the original instructions, in a different language. You can't understand them, but the clerk can work with them more easily.

A bright clerk - or compiler - can incorporate other improvements into the new set of instructions. For instance, an old card might say 'empty the 200th bucket', requiring the worker to count through the buckets from the start to find the correct one. The new clerk might be able to re-write the instruction, or make a map, so that the correct bucket (or variable, or program line) can be found at once. This saves time, as long as the situation is consistent. If changes are required a new set of specific instructions must be made.

To summarise: interpreters are quick and simple while you're working out what needs to be done, but compiled instructions are more efficient once you know what to do.

NITTY GRITTY

If a BASIC interpreter is very inefficient, and the underlying task is very simple, a compiler can make BASIC hundreds of times faster. In other cases - say, when evaluating trigonometric functions Y printing to the screen - the interpreter and compiler work at much the same speed. The time needed to interpret such commands is small compared to the time needed to carry them out.

ZX BASIC is a 'general purpose' language, which makes it concise and easy to learn, but sloppy. All numbers are held in a fiddly floating point form which the computer must work with, piecemeal. An enormous range of numbers can be handled, to nine digits of precision - but that's often a vast overkill.

The processor can handle whole numbers of up to five digits much more easily, but ZX BASIC does not take full advantage of these common 'special cases'. The interpreter struggles on, doing everything slowly, the hard way. Every number is kept in five bytes of memory, even if it would fit into one or two.

String handling is similarly messy. ZX BASIC has no way of knowing how big an undimensioned string will become as a program runs. It chooses to shuffle values around to make room as required. This usually means that it spends more time moving other things out of the way than it does storing or recalling your text. That doesn't matter much when you're testing a new program, but it makes finished software much slower that it need be.

THE AIM

The aim of a BASIC compiler is to give you the speed of machine code - and hence the freedom to use animation, sound effects, and other time-intensive techniques - while still letting you develop your program in friendly, familiar ZX BASIC.

It's easy to learn BASIC, and mistakes are usually obvious and easy to fix. By contrast, machine code programming is complicated, repetitive, pedantic and hard to test. It's just the kind of job you should give to a computer - hence the existence of compilers.

Real programs, and the programmers, are hard to compare, so meaningless but standard programs (called 'benchmarks') are used to test interpreters and compilers in a quantitative way. I've tested HISOFT BASIC in this way, to see how it stands up to the competition. But benchmarks are far from the whole story, so I've also given HISOFT BASIC some 'real' programs to chew on.

ELECTRIC HACKERS

Before HISOFT BASIC arrived there were two main types of ZX BASIC compiler. Some required you to adapt your program, or write it in a special way, so that it could easily be re-expressed in machine code. These compliers - such as SOFTEK'S IS, HISOFT'S Colt, and my own ZIP - cannot cope with decimal fractions and limit the use of arrays or strings.

These 'subset' compilers can give very good results. They are easier to use than compilers for other languages, because you can test programs beforehand with the interpreter. But they're really just a 'middle ground' between BASIC and machine code. You need quite a lot of knowledge to use subset compilers effectively. They're not a general solution if you've got a slow ZX BASIC program and want to make it faster with the minimum of fuss.

ACCELERATORS

The other sort of compiler is aimed at people who have already got a program, and just want to speed it up without having to study or rewrite the code. 'Full' compilers can cope with decimal numbers as well as whole numbers ('integers') but their code is usually 10 to 30 times slower than that of more restrictive compilers. There's a trade-off between compatibility and speed, in that compiled code tends to get slower as it works more and more like the interpreter.

General-purpose compilers are hard to write. The first Spectrum one was SOFTEK's FP, which coped well with sums and strings but had quite a few restrictions. It couldn't handle user-defined functions and calculations after GO TOs or DATA. It also banned arrays of more than one dimension.

BLAST was a compiler that sounded wonderful but never worked properly. The publishers, OXFORD COMPUTER SYSTEMS, went bust not long after it was launched. In many ways HISOFT BASIC is what BLAST should have been - and carries the same £25 pricetag, But 18 months ago Mcoder III arrived, from ERE iNFOMATIQUE via PSS. To my mind, Mcoder III is the best French program yet released in the UK. It will compile almost anything, although it draws the line at array re-dimensioning and 'add-on' (for example, Microdrive) commands.

Mcoder III is stylish - it runs entirely in video memory, shares variables with normal BASIC, and generates a mixture of compiled and interpreted code with many optimisations. But the documentation is poor, compilation is slow, with two mandatory tape loads, and the implementors have taken a few 'short cuts', trading compatibility for speed.

THE CONTENDER

HISOFT BASIC will have to beat Mcoder iII if it is to 'surpass all others' as HISOFT claim in their manual. It was originally written in Canada on a TMS-2068 - an American Spectrum. HISOFT have improved it and added full support for the 128. Their magic formula is a combination of the speed of the restricted compilers with the flexibility (at comparable speed) of the 'full' versions.

"HISOFT BASIC combines the advantages of these two types of compiler without any of the disadvantages", the publishers crow, claiming "simultaneously the fastest integer compiler and the fastest floating-point compiler available for the Spectrums."

DOCUMENTATION

These quotations from the manual sell it short - after a page and a half of hysterical self-congratulation it launches into a readable, well-designed tutorial. The compiler loads in 100 seconds from tape. It can be moved to disk or Microdrive without much hassle. It won't work with some SAGA keyboards, but SAGA have admitted responsibility for the probLem and will supply a 'fix' to anyone who runs into trouble.

Nine small demonstration programs follow the code on either side of the tape. The examples are well-chosen to illustrate the way directives - extra REM statements - are used to control compilation.

A simple graphics demonstration is 3.3 times faster after compilation. A compiler can speed up the number-crunching but it can't do much to change the amount of time actually spent plotting points on the screen.

A loop PEEking and POKEing display information is 15 times faster when first compiled; an extra directive, to say that some variables are integers, makes it 409 times faster than BASIC! This is a 'perfect' example, in the sense that it is something machine code does very well and BASIC very badly. A graphics program working from DATA with DRAW is about four times faster after compilation - this ratio looks more impressive than it sounds.

The Sieve of Eratosthenes is a program to find prime numbers. It's another near-ideal example, although I found it easy to condense and speed-up HISOFT's original BASIC. The compiler ran The Sieve about 174 times faster than ZX BASIC. ZIP - once the speed champ - accelerates the same code by a factor of 160.

The last two examples are sorting routines, which HISOFT BASIC makes 20 times faster. The lines that generate random data for sorting only speed up by about 50 per cent. I compiled several games and utilities from my own collection, and found HISOFT BASIC fast-working and reliable. I found one minor bug - STOP and RETURN are treated as the same instruction, so you can't STOP inside a subroutine.

The 50-page A5 manual by programmer Cameron Hayne reached HISOFT in handwritten form! The publishers have neatly laser-printed it, but it is easier to read then it is to use - it's more a collection of interesting essays than a reference guide. The tutorial is excellent and the other parts seem quite comprehensive, but examples are rare and the lack of an index is inexcusable.

IN USE

The compiler is started by typing *C. Programs of up to a hundred lines or so are compiled almost instantly. A 3.5K ZX BASIC game compiled into 3.2K of integer code in about eight seconds. As HISOFT BASIC compiles your program, gibberish appears on the screen, which is used as a temporary store to free other memory for code.

Messages indicate errors, routine addresses, and the length of interpreted and compiled code. You must press a key twice to clear messages and step between the phases of compilation. The compiler stops as soon as one error is found. HISOFT BASIC works so fast that this is not an irritation. You can fix the offending line at once - just press EDIT.

Compiled code can be started with *R, or a RAND USR command. *X clears out all the code, but it doesn't tell the system, so a subsequent *R will usually crash the computer - beware!

*T is the most innovative feature - this controls a 'trace' which keeps track of variable values as a program is interpreted at about half-speed. When you stop the program you can see a list showing which variables were only used to hold integers, and the maximum length strings reached. If you test a program thoroughly while using *T you can use the list to tell HISOFT BASIC which optimisations to perform, and thus get the speed of a 'subset' compiler with no need to study the code yourself.

COMPATIBILITY

HISOFT BASIC is more restrictive than Mcoder III, but probably a little more compatible. Mcoder tries to 'guess' at optimisations, but HISOFT expect you to indicate them by adding directives in REM statements. These indicate signed and unsigned integer variables and maximum string sizes; the default is a rather wasteful 255 characters.

Arrays of one or two dimensions - but not more - are allowed. Dimensions must be fixed, not calculated as a program runs. VAL only works with numbers in quotes, and not with numbers in strings - an annoying limitation. CLEAR and RUN are banned, as are expressions in DATA, disk and Microdrive commands. The music command PLAY works fine on any 128, and is ignored by earlier computers.

Minor quirks include a limit of 450 targeted lines for GO TOs, no coercion in READ (so you must mark integer DATA statements), and no CLS when a program starts. PLOT, DRAW and CIRCLE assume the current colour attributes, for top speed, so you may have to add PAPER 8 or BRIGHT 8 statements in a few places. Division is always done with floating-point arithmetic - even if you're using integer variables - unless you put an INT around the division.

You can generally break into compiled code in the usual way while the compiler is loaded, but not thereafter. INPUT statements are BREAK and crash-proof. The new BREAK scan stops ZX BASIC messages, so you can't tell what line you were on, even when you BREAK normally into the interpreter.

Code is concise, as library routines are not included unless they are required. Floating-point programs tend to grow by about 20-30 per cent as a result of compilation, whereas programs that use integers exclusively usually shrink a little. A convoluted 15K ZX BASIC program was compiled into 20K of machine code in about 80 seconds.

There is 29K free for BASIC and compiled code on a standard Spectrum. You can compile code and DATA separately if there is not room for everything together. HISOFT BASIC can also work a bit like Mcoder III, overwriting BASIC with compiled code, if you give the word. Spectrum 128 users get the best deal. They can put the compiler entirely on RAM disk, allowing up to 40K of code in memory at once. HISOFT BASIC also soups-up the 128's BASIC editor.

SPEED TRIALS

We have printed two sets of Benchmark ratios for HISOFT BASIC, showing the speed of floating-point and signed integer code. The table also shows the code tested and the benchmark ratios of the two fastest compilers of 1985 - ZIP 1.5. for integer-handling, and Mcoder iII, tops for flops (FLOating Point OPerationS, dummy!). Each number is the ratio of the ZX BASIC time to the compiled time.

ZIP, MCODER III and HISOFT BASIC - BENCHMARK RATIOS

Code: FOR Loop
Test: 1
ZIP: 158
HISOFT BASIC (Integer): 162
HISOFT BASIC (Floating Point): 5.84
MCODERIII: 42.0

Code: IF loop
Test: 2
ZIP: 141
HISOFT BASIC (Integer): 185
HISOFT BASIC (Floating Point): 6.60
MCODERIII: 10.7

Code: Var arith
Test: 3
ZIP: 113
HISOFT BASIC (Integer): 233
HISOFT BASIC (Floating Point): 3.00
MCODERIII: 3.3

Code: Num arith
Test: 4
ZIP: 192
HISOFT BASIC (Integer): 238
HISOFT BASIC (Floating Point): 2.73
MCODERIII: 3.1

Code: 4+ GO SUB
Test: 5
ZIP: 219
HISOFT BASIC (Integer): 265
HISOFT BASIC (Floating Point): 3.32
MCODERIII: 3.7

Code: 5+ loop
Test: 6
ZIP: 216
HISOFT BASIC (Integer): 219
HISOFT BASIC (Floating Point): 4.99
MCODERIII: 7.7

Code: 6+ arrays
Test: 7
ZIP: 191
HISOFT BASIC (Integer): 197
HISOFT BASIC (Floating Point): 6.20
MCODERIII: 8.8

Code: FP Maths
Test: 8
ZIP: N/a
HISOFT BASIC (Integer): N/a
HISOFT BASIC (Floating Point): 1.11
MCODERIII: 1.13

The table shows that HISOFT have succeeded in one of their aims - to produce a top-speed subset compiler - but Mcoder III is evidently an unknown quantity in Canada. You should read TECH TIPS Cameron!

The compilers have all been specially tuned to compile such arbitrary benchmarks, but it appears that HISOFT have neglected their floating-point routines, most of which just call the Spectrum ROM. In real programs Mcoder may have less of an edge, especially as it leaves DATA and functions un-compiled, but it's still a serious competitor for HISOFT BASIC if you don't want to bother with REM directives - especially as it's half the price.

If you've got a 128, or lots of programs to compile, or you want to produce commercial software without paying royalties, HISOFT BASIC is the best compiler on the market. It is well-designed and HISOFT have a good reputation for supporting and developing their products. But the price is high, although you get a lot for your money. HISOFT BASIC is going to do well, but it won't sweep the market.


REVIEW BY: Simon N Goodwin

Transcript by Chris Bourne

Crash Issue 50, Mar 1988   page(s) 61,62

(Simon N Goodwin owns the copyright to this review. Please visit http://simon.mooli.org.uk to find original articles and updates, much new material and his contact details.)

SOFT BUT STRONG

Power to the programmer from software tools

HISOFT'S HIGH-SPEED COMPILER

At £29 HiSoft BASIC 1.2 is slightly more expensive than version 1.0, but it boasts disk commands and other improvements. The generated code is no faster, but that's no surprise - it's still the fastest integer BASIC compiler on the Spectrum, with ZIP second. And HiSoft BASIC is second only to MCODER 3, a much simpler product, when it comes to floating-point maths.

Both the minor bugs in version 1.0 have been fixed in the new version.

ADDED VAL-UE

The first enhancement of version 1.2 is an improved VAL function, similar to that of HiSoft's other compiler, The Colt. Version 1.0, like most Spectrum compilers, only allowed you to take the VAL of a string of digits, whereas the interpreter can work out the value of any expression - even if you include function calls and references to variables in the string.

If a compiled program handled VAL like the interpreter it would need to compile the expression every time VAL was called. This would be horribly slow and clumsy - you'd need the entire compiler loaded, along with the temporary data it generates when allocating space for variables, whenever VAL was going to be used. And as soon as you'd generated the code for each call you'd have to execute it and then throw it away!

HiSoft doesn't go to that extreme - this compiler calls the Sinclair BASIC interpreter's VAL routine from compiled programs. VAL is as slow as ever after compilation, but no extra code is needed to work out the value of functions, calculations and variables.

The snag is that variable and user-defined-function names used in VAL refer to the current ZX BASIC program variables - not to variables in the compiled program. The new VAL is an improvement over version 1.0, but still a compromise of speed, conciseness and compatibility.

FILES

For some reason Amstrad didn't put any facilities to handle text files in +3 BASIC. You can SAVE and LOAD individual arrays, but you can't handle files that won't fit in memory (there's no such restriction if you're using microdrives or third-party disk systems such as the Disciple, Discovery, Plus D and Swift Disc).

But HiSoft has fixed this + 3 limitation in its BASIC compiler. You can OPEN and CLOSE text flies, and then read and write them with INPUT, INKEY$ and PRINT. The syntax is simple and standard.

There are limitations - you can't wind back and forth in a file, though +3 DOS theoretically allows random access, and you can't detect the end of a file unless you read the data one character at a time with the slow INKEY$ function. INKEY$ returns an empty string when the end of a file is reached.

File-handling only works if you run the compiled program on a +3 and load the few hundred extra bytes of code supplied in a file called RUNTIME. Programs that don't use files will run independently on any version of the Spectrum.

EASY TO USE

+3 HiSoft BASIC is very easy to use, with a menu of single-key compilation options.

The compiler and menu fit into the parts of the 128K memory which are not normally available to BASIC, leaving 42K of space on drive M and about 40K for your original BASIC and the compiled code. If you're really pushed for space you can compile the code and DATA separately; this is a fairly painless process on a disk system.

Version 1.2 comes with the same demonstration programs as 1.0, plus two simple but neat BASIC arcade games. The games are limited graphically as they rely on redefined character graphics, but they're a good starting point for learning how to write games.

The first game, a Pacman clone, starts life as 6K of slow BASIC and compiles into 9.5K of machine code in 9 seconds. The compiled code draws the maze eight times faster than the ordinary BASIC game, and moves the man and the monster about 6.5 times faster.

The second example, a 7.5K BASIC Frogger game, compiles into 10K of code in just 8 seconds. The speed-up is smaller, as Frogger reprints most of the screen regularly, but it still makes the difference between a slothful game and a playable game.

These results are quite impressive, though you shouldn't read too much into ratios for a couple of programs. Code that relies on integer arithmetic, rather than relatively slow graphics, can go hundreds of times faster after compilation. But at the opposite extreme, trigonometrical calculations are hardly accelerated.

HiSoft BASTC was highly recommended for the old Spectrum. On the +3 it's even better - if you program the new Amstrad Spectrum in BASIC, get version 1.2 for faster programs. For HiSoft's address, see the DevPac article in this section.


REVIEW BY: Simon N Goodwin

Transcript by Chris Bourne

Sinclair User Issue 56, Nov 1986   page(s) 110

Label: HiSoft
Author: In-house
Price: £15.95
Memory: 48K/128K
Reviewer: Rupert Goodwins

Is your Basic boring? Do your programs dawdle through data, and saunter through subroutines? Perhaps Hisoft has the answer with its Basic Compiler.

You know Basic. Great fun to dabble with, but a bit lacking in the speed department. Compared to the Ferrari of machine code, Basic is a 2CV. There's nothing you can do in the former you can't do in the latter, but boysoboys, what you do, you do faster. And with style.

Basic, as found on your Spectrum, is slow for a number of reasons. The biggest problem is the way in which the computer deals with the program. For each line of Basic, the machine laboriously works out its meaning, what memory to use and how it all links in with what's gone before. Then, and only then, the computer knows enough to obey the instructions on that line. If it ever goes back to that line, which in a program with Gotos, Gosubs and For... Nexts it will, it has to carry out all that work again, before it can produce a result.

So, short of diving into the horrors of hexadecimal, how do you speed things up? The answer is a compiler. A compiler goes through a Basic progam and does all the checking and translating. Instead of then running the results, it stores them as machine-code commands in an area of memory. When the time comes, the user (that's you) treats the compiled program like a pure machine-code program. As all the checking's been done once and for all, the program runs much faster.

There have been Spectrum compilers about for a while. Unfortunately, they've traditionally been restricted by their inability to cope with various commands, forcing the user to modify programs to take account of their limitations.

This HiSoft Basic compiler is (almost) innocent of such sins. You load it in, load or type in just about any Basic program, and utter the appropriate magic words '*C'. A few seconds later, you have a machine-code program that does everything your Basic did, but faster.

How much faster depends on a lot of things. If your program depends heavily on Rom-based graphics commands like Circle or Draw, then you can only expect a three-to ten-fold increase in speed. But if it spends a lot of time doing simple maths, or string handling, the acceleration can be breathtaking. HiSoft supply a set of demo programs, including one called 'Sieve'. This is a standard benchmark for compilers, as it works with simple numbers in a way which any compiler worth its salt should really go to town on. HiSoft Basic's compiled version goes more than 150 times faster than unaided Basic. That's fast.

There are commands which the compiler can't deal with. Mostly these are 'system' commands, like Save, Load, Clear and so on.

To tell the compiler to start compiling a section of your program, include a line Rem : Open #. The line Rem: Close # stops the compiler producing code. For every Open # - Close # pair a chunk of machine code is generated, and the compiler prints the start address of that section. Replace the Basic sections with Randomize Usrs of the appropriate address, and it all works.

The only serious omissions are some of the naughtier things you can do with arrays, and the ability to compile Val A$ (although Val A$ '2314' is OK). This function is very useful, and can be difficult to replace by other bits of Basic.

The manual is good. There's a short tutorial, which works with the example programs provided, and several reference sections covering commands, memory maps and errors.

The size of the compiled code is bigger than the Basic program which spawned it. This is because the code needs some support software (known as runtime routines) but HiSoft Basic does its level best to minimize the problem. Some compilers load in the complete set of routines for every program. HiSoft Basic Compiler just uses the relevant ones.

It allows you to select just the right way to deal with a variable, so if a variable will never be a number with a decimal point in it, then you can tell the compiler to store it in an efficient format. The compiler can look through a program while it runs, and tell you which variables are candidates for this treatment. Other things the compiler itself looks for include divide and multiply by two, as commands such as these can be coded into very fast machine language indeed.

The compiler takes three passes through the Basic program to produce its result. During each pass, it uses the screen memory to hold information and lists. This is quite a good idea, as after a while it's possible to judge what's going on by looking at the dots and colours whizz past, but to the uninitiated it does look horribly like a crash.

Does it work? I dug out my stock of Basic programs (on WH Smith C15 tapes!), and ran them through the mill. On average, it took about ten minutes to convert and produce an efficient compiled version, and nothing proved uncompilable.

Very impressive. The Breakout game on the old Spectrum Horizons tape ran far too fast to even see, let alone play...

You get two compilers on two tapes for your money in the videotape size pack. The 48K version is about 10K long (leaving room for roughly 30K of Basic), and uses direct commands prefixed by a *. The 128K+2 version is a bit more subtle.

It has about 500 bytes of program in the Basic area, but mostly lives in the silicon disc, thus leaving around 40K of room for your evil doings. It has a menu system for commands, brought into life by pressing True Video and Inv Video at the same time. These keys are also used as special shifts in conjunction with the cursor keys to duplicate the elusive keypad's editing functions. Don't try bringing up the compiler menu when the Basic's Option menu is up, as things can get confused! Both versions transfer to Microdrive with the minimum of fuss.

The only reason I can think of for you not buying this program is if your knowledge of Basic goes no further than Load "".

Even if you know Z80 machine-code backwards, the compiler lets you cook up a concept in Basic, debug it and then commit it to code fast enough to make dabbling a delight.

And for those who know Basic and type in the odd listing or two. this compiler must be nigh on invaluable.

Don't expect to rewrite Elite, but Basic is fun again.


REVIEW BY: Rupert Goodwins

Overall5/5
Summary: If you ever write anything in Basic or machine-code this program is a must. It works like magic. Buy it.

Award: Sinclair User Classic

Transcript by Chris Bourne

ZX Computing Issue 34, Feb 1987   page(s) 23

Hisoft
£15.95

Hisoft are a company famous for their Devpac assembler which is the assembler all others are measured by. They are not a prolific producer of software, but usually when they do market something it is of a very high standard.

Now BASIC as we all know, is useful for learning to program and is tolerable in some applications where speed is not essential. To get an arcade type of program to run at a reasonable speed on the Spectrum you need to program in machine code and that takes a fair bit of serious study.

Alternatives are to use a special language such as White Lightning or to get a compiler to change BASIC into machine code.

The latter has been attempted with reasonable success by PSS with MCODER 1, 2 & 3, the last being an excellent compiler with few disadvantages, the biggest being the compiled code is not relocatable and it is not possible to combine several routines compiled separately. BLAST on the other hand was a disaster and its name aptly mirrored its purchaser's expletives.

FLOATING POINT

The HiSoft compiler is a full floating point (copes with decimals as well as integers, ie, whole numbers), compiler for all the Spectrum variants. The code itself occupies around 11K.

HISott claim this means that programs up to 30K can be compiled in one operation, 128 and PLUS 2 owners have a slightly modified operating system which takes advantage of some of the capabilities of the machines.

The compiler code is located low in memory between the system variables and the microdrive map area. Memory maps of the program's requirements are given in the manual.

Limitations are few and are unlikely to be restrictive unless you require them for a specific programming purpose. These are that no expressions are allowed in DATA statements, evaluations of string variables (eg. VAL x$) is not allowed and arrays of three or more dimensions cannot be used.

There are also a few system commands which are not allowed but these can be overcome due to the compiler's ability to move in and out of BASIC selectively, these are such commands as LOAD, SAVE, NEW etc.

Although supplied on tape there are instructions for making a Microdrive or disk backup copy, a considerate and useful option.

The compiler has sixteen directives although often only one or two may be required and these are used by adding REM: lines before the start of the code to be compiled.

One compilation is initiated then all relevant info is provided, including entry points if the program was split into sections, and at the end the start and length of code for saving to tape etc is given.

ON TEST

First the 50 page manual deserves d congratulatory mention. I took it away and read it and due to its step by step examples I understood it without any problem and felt confident when I went back to the computer.

My first difficulty came when I loaded the program and tried to convert it to run on my disk drive system, it wouldn't! Then I tried running it direct from tape, it locked up!

Only when I disconnected my drive would it work, now the problem is that I am using a TRL Beta interface and it is obviously incompatible with it. I assume that the Disk drive they refer to in the manual is the Opus Discovery which is compatible with the microdrive system. A bit of a disappointment.

The program was now working and the short demos/examples worked perfectly and impressively. This is the only compiler I know which can handle Sinclair's computed GOTO and GOSUB features.

SPEED LIMITS

The speed increase was variable but this is explained, and reasonably so, as being dependent on the number of 'real' number calculations needed and use of the PLOT/DRAW functions. By specifying integer and positive integer variables at the start by using the directive REM: iNT variable, list the speed increase is optimised.

Error messages are clear, detailed in the manual and are produced on either of the first two of the three passes the program makes.

My next test was to try and find a BASIC program on tape (all mine being kept on the inoperable disk drive) eventually I found a couple and of course the first included a DIM A(2,4,3) instruction which is not allowed.

The next was a copy of an earlier ZXC listing called Platform Jack, a rather slow jump game. It compiled after three attempts when I had to make minor amendments to RUN statements and gave a speed increase of about 20 times! Completely unplayable without the addition of some delay loops.

Out of the four other games I experienced no problems and all gave an impressive gain in speed. I did find that in general the code produced tended to equal or become slightly longer than the original and this meant that in practical terms around 11K to 15K was compilable in one go. For really long programs then it may be possible to break them into smaller units and compile to specific addresses. A special facility to compile DATA and program separately is built into the program.

I am proud to note that ZXC is credited at the end of the manual for allowing the use of one of Toni Baker's published routines for the 128 keypad simulator.

Probably the most versatile general purpose compiler on the market it has a little more flexibility than PSS' Mcoder 3 which must be its nearest rival.

It could certainly produce commercial quality programs of some types, but to produce that state-of-the-art graphic arcade masterpiece is unlikely without custom written machine code routines.

If you're serious about your computing then this is the program you've been waiting for, as close as anyone is likely to get to an easy to use, most features supported compiler for the Spectrum computers.


Transcript by Chris Bourne

All information in this page is provided by ZXSR instead of ZXDB