CURRENT NOTES: The Newsletter for Atari Owners JUL/AUG 1986 ======================================================= P H I L O N F A S T / B A S I C - M C O M P I L E R F O R T H E 5 2 0 S T Reviewed by Stephen Eitelman ======================================================= Introduction and Major Conclusions. ST Basic supplied with the 520ST is an interpreted language. This means two things. First, in order to run a program, ST Basic must be loaded into the machine, then the particular program loaded and run. Second, as each Basic statement is encountered, the interpreter must locate the machine language code in its library and execute it. The advantage of this arrangement is the ease of interactive editing both during entry of the code and during program execution. The major disadvantage is lack of speed for long loops, because each command is translated each and every time through the loop. Another disadvantage is the inability to run an application directly from the GEM desktop - ST Basic must be loaded first. Philon has created a compiled Basic for the 520ST. A compiled Basic translates the entire program into executable machine code and stores this on disk. The program thus does not consume any time translating individual commands into machine language during execution of the program. In principle, programs that are very long and/or contain lengthy loops can be speeded up significantly by compilation. Engineering, scientific, game and business programs are typical categories. A very efficient programming technique is to write a program with an interpreter, debug it interactively with the interpreter, then compile it for speed and execution from the desktop. The Philon compiler achieves this, except for speed in mathematics routines. During the course of this review, two speed tests were run. One test was a repetitive number cruncher and the second, a character string sorting routine. The math test ran SLOWER under the Philon compiler than it did from ST Basic, while the sort test ran faster. The Philon code does run directly from the desktop and will compile ST Basic files, provided the commands used in the ST Basic file are common to the Philon dialect. The major uses for the compiler would be in applications requiring considerable math accuracy. Engineering, scientific and business applications seem appropriate, although they may run slower than expected. Additionally, the compiled program runs directly from TOS - loading ST Basic is not required. ST Basic has a rather large vocabulary of about 170 commands. Of these, there are 60 that are not available to the Philon compiler, leaving about 110 common commands. The major categories of non-compilable commands are: - Graphics - Sound ST - 1 - ST CURRENT NOTES: The Newsletter for Atari Owners JUL/AUG 1986 - Window control - Programming and debugging aids - VDI and AES calls There are 23 commands available in the Philon dialect that are not supported by ST Basic. They are largely compiler directives, but there are two very useful commands - PRINT@ which allows specification in x-y coordinates of the location on the screen where the PRINT is to occur and INKEY$ which causes the CPU to wait for an input from the keyboard before executing the next command. Installation. When the Philon package is first opened, it is intimidating. There are five disks and a three ring binder of documentation 5/8 inch thick. Fortunately, this mountain of paper is mostly reference material describing each command in exquisite detail and is not necessary for many compilation tasks. What the documentation desperately needs is a "Read Me First" sheet in the very front of the document. In fact, all that is needed to get started are the Installation Instructions - 4 sheets of paper stapled together in the pocket on the inside back cover. Installation proceeds very smoothly in nine steps and the final few steps include the enormous satisfaction of compiling a sample program and seeing it run. POTENTIAL BUYERS BEWARE: The minimum hardware configuration absolutely requires two floppy disk drives. The compiler CANNOT be used with only a single floppy drive. A single floppy drive and a hard disk is the preferred combination. This configuration will compile faster and avoids disk swapping. Typical compilation time is a lengthy 20 minutes using two floppies and requires swapping disks 2, 3 and 4 (in order) in drive B while leaving disk 1 in drive A. Compilation of the Philon sample program is an excellent introduction and the source code provides a very useful model. Preparing Source Code. Having gotten the compiler installed and the sample program compiled, the urge to write my own test program and try it was overwhelming. Once again, there seemed to be an insurmountable barrier: How is source code created? There is no editor shown in the table of contents. As a last resort, I began reading the documentation. The beginning of Chapter 2 says that "any standard text editor" can be used. At this point the light dawned: Look on the utility disk which was used for installation. And lo: An editor called Micro EMACS plus a 60 page tutorial can be found. (The expansion of the acronym EMACS is Editor MACroS - created at MIT sometime between the dark ages and the rennaissance.) Once again, the light dawned: ANY word processor, text editor or Basic interpreter capable of producing an ASCII file can be used. This means that a program can be written in ST Basic, saved to disk, run under ST Basic to interactively debug it and then compiled with the Philon Fast/Basic-M compiler. As an intermediate step, word processors such as ST Writer and Regent Word (but not 1ST Word) can be used to edit the source code in order to change non-common commands. As an example, CLEARW2 must be ST - 2 - ST CURRENT NOTES: The Newsletter for Atari Owners JUL/AUG 1986 changed to CLS to go from the ST Basic dialect to Philon's dialect. The search-and-replace function in most word processors can be used for such changes. Alternatively (and pretty risky!), the entire program can be written with a word processor and compiled. Debugging a compiled program quickly makes one apppreciate an interactive interpreter. Compilation. Once the source code is created and stored in ASCII format it can be compiled. The file must be on disk one. Since the compiled files are quite large (on the order of 70K bytes), only one compilable program should be on the disk at a time; otherwise the disk fills up during the final linking process, producing an enigmatic LINK68: WRITE ERROR ON FILE: .68K. If this error appears, it means the disk is full. (Why can't they say so? It cost me a $1.75 phone call to Philon to find this out!) In any event, disk one with source code goes in drive A and disk two in drive B. The source code MUST have an extender of .MB. On screen directives will indicate when to swap disks - this is done in drive B only. Disk one remains in drive A. Patience is required when running disk four. It typically requires about 15 minutes to complete the linking. If all goes well, you will be rewarded with an unceremonious return to TOS. Double click on .PRG and it should run. Speed Comparison. After all this discussion, just how fast is a Philon compiled Basic program? Sadly, I'm forced to conclude that for math applications, it is just plain SLOW. And math intensive applications are a major motivation for buying a compiler. Since the compiler will not compile graphics commands, it is not especially useful for compiling games written in Basic either, unless all graphics are done through VDI calls. Sorting applications, however, do appear to run substantially faster. Two rather different speed tests were run. The actual numerical results are shown in the table. One test was a number crunching test that calculated the square of the cosine of an index that varied from one to 10,000. This test was not intended to be exhaustive; rather it evolved from a desire to walk into any computer store and try out something quick and dirty as a rough speed comparison between different machines. The other test was a random character string test. The program was arranged in three parts. The first part generated 1000 random strings; the second part sorted the strings alphabetically and the third part simply printed the alphabetized list to the screen as proof that the program worked. Comparison of ST BASIC and Philon BASIC Speeds (Execution Times in Minutes:Seconds) ==================================================== Test: | A | B | C | D | ==================================================== ST - 3 - ST CURRENT NOTES: The Newsletter for Atari Owners JUL/AUG 1986 ST Basic | 0:51 | 1:09 | 5:04 | 1:45 | | | | | | Philon | 1:39 | 2:04 | 2:25 | 0:36 | | | | | | Opt. Philon | 1:37 | 2:04 | 2:25 | 0:36 | ==================================================== Test Description A 1<=I<=10000, COS(I)^2 B Generate 1000 random strings C Sort 1000 random strings D Print sorted strings to screen ==================================================== Note that the math test required almost twice as long for the compiled version to run compared to the interpreted (ST Basic) version. Now that is awful! There are two reasons I can think of: (1) Philon uses 64 bit words for a numerical accuracy of either 14 or 16 significant figures. ST Basic uses 32 bit words for a numerical accuracy of 6 or 9 significant figures. The extra word length takes time. (2) Philon apparently links the entire library of Basic functions to the program rather than only the functions actually needed. It is possible that the program must examine the entire library in some fashion to find a needed function. The evidence for this is that the optimizer directive which is supposed to remove unused code does not create appreciably smaller files - nor do they run significantly faster. Yet a very simple program to print out a statement requires on the order of 70K bytes of machine code! The actual sort portion of the compiled version of the second program ran in somewhat less than one-half the time of the ST Basic interpreted version. Now that's more like it! Note also an almost 3:1 speed up in printing out the strings on the screen. Final Thoughts. I had occasion to call the company twice. It is refreshing to find a telephone number that works on page 1-1 of the manual. Both calls were answered promptly and courteously; I was referred to someone who listened, was willing to help and, miracle of miracles, called me back in about half an hour with the answer to my problem! The compiler exhibited NO bugs, although I did not exercise all the bells and whistles. Nonetheless, I think this is remarkable for a new product. The version I reviewed (V1.3) does not support graphics. An updated version 1.35 claims to support graphics, but only through rather complicated VDI calls. It will not compile such commands as COLOR, CIRCLE, PCIRCLE, etc. -------------------------------------------------------- Steve Eitelman, a design engineer in private industry from 1965 to 1973, is currently a supervisory electronics engineer with the US ST - 4 - ST CURRENT NOTES: The Newsletter for Atari Owners JUL/AUG 1986 Army. Steve received a BS degree in EE from RPI in 1961 and an MS in EE from the Florida Institute of Technology in 1967. Hobbies include micro computing, ham radio, and weekend sailing. -------------------------------------------------------- ST - 5 - ST =========================== Test Description: A: 1<=I<=10 000, y = cos(I), x = y * y (Fast cos squared)