80-Bus News |
Summer 1985 · Volume 4 · Issue 2 |
Page 17 of 31 |
---|
This compiles TESTPROG, lists it on the printer and enables error checking to take place in the .INT file and providing a message on the screen (the bit in lower case, although it can be in upper case if you want, or even omitted!).
TRACE is a useful facility which can be called upon when a compiled CBASIC program is run using CRUN. If TRACE is called without parameters, the trace of execution of all lines in the program is carried out but the extent of tracing may be altered by including the line numbers as appropriate:
CRUN TESTPROG TRACE 1,10 - traces the execution of lines 1 to 10 CRUN TESTPROG TRACE 9 - traces the execution of all lines after and including 9 CRUN TESTPROG TRACE - traces the lot!
CBASIC produces (when appropriate) both Compiler and RUN-TIME error messages which are self explanatory. It also produces two-letter error codes which are expanded upon i na closely printed 6 page appendix in the User Guide — and if the E toggle is employed at compilation time, a little more information is produced including an indication of the offending line and the probable position of the error on that line.
In spite of what the User Guide says, the simple error messages are not immediately intelligible. When the expanded error message is produced it says:
ERROR SE IN LINE 123 AT POSITION 14
OK, SE means syntax error, line 123 is the 123rd line of the compiler listing, not statement label 123 and position 14 means the 14th column on the screen or printout. In fact, the error may have been caused by something in a preceding line or by the omission of something earlier on in the program {such as a variable which has not been previously declared in a DIM statement). It might be on the line which is indicated, or even its predecessor(s), particularly if the \ feature is used to break up a line — MORAL — don’t use the \ feature unless you are confident, and for the first few trial compilations, do use the F toggle to get hard copy of your errors.
CBASIC is not really designed for the inefficient, impulsive or non-structured programmer, but it has some excellent features which render it very useful for commercial or scientific applications. Until Microsoft dropped their absurd royalty claims on published programs written in compiled MBASIC a couple of years ago, it was the preferred BASIC language used in commercial software and the CP/M User Group library. Benchmark tests show that it is somewhat slower in single precision arithmetic than compiled MBASIC (but it works to nearly double the level of precision). It appears to be more accurate in handling numbers with several significant figures, but I have not tested this exhaustively yet; a future article on benchmarks will deal with this aspect and will include comparisons of both BASICs and some other languages (including P*SC*L and F*RTR*N) on 80-BUS machines. Although it is not available from Gemini, several software houses will supply it at round about £120 — about half the price of the MBASIC interpreter. DRI’s CB-80 which has a true compiler currently costs about £400.
All things considered, CBASIC would be an excellent choice in terms of cost and facilities for the user who is updating from a cassette-based to a disk-based system for serious applications. Before committing oneself to its purchase, it would be worthwhile getting hold of copies of EBASIC and ERUN to see how the idea of a semi-compiled language appeals to your style of programming. EBASIC is said to be compatible with CBASIC but lacks some of the more advanced features, so EBASIC programs should run satisfactorily on your CBASIC system.
Page 17 of 31 |
---|