Review: Lattice C 5

From ST Report No 701

The Lattice C Version 5 (LC5) compiler is a modern compiler with one of the most complete libraries available for the Atari ST/TT platforms. LC5 is a complete ST development package including the C compiler, a full screen GEM editor, an assembler, a resource construction set, a global optimiser and various library manipulation programs. LC5 complies with the ANSI Standard X3.159 with the single omission of trigraphs. This review is of the Version 5.06.02 compiler which I recently purchased at the W.A.A.C.E show in October and have since used for porting several programs from the UNIX environment. LC5 is developed and supported by HiSoft of England. JOPPA COMPUTERS also carries the LC5 package. I would recommend registering your copy immediately and inquiring from HiSoft about the latest version. I have found HiSoft to provide excellent updates and are regularly updating the package. Thus, your copy from JOPPA COMPUTERS may have been updated since Joppa received it!

Review System

I am reviewing the HiSoft Lattice C compiler on a Mega ST with 4 megabytes of RAM, TOS 1.4, the FAST TECHNOLOGY Turbo-16 accelerator, and a monochrome SM124 monitor. I also use the Atari color monitor but prefer the monochrome for everyday editing. I generally use the color monitor to construct color resource files and to verify the operation of my programs in low and medium resolutions. I am using a 130 megabyte hard drive system from ABCO Computers Inc. LC5 requires approximately seven meagbytes on my system. I use NeoDesk 3.0 (from Gribnif Software) as the GEM Desktop, and Micro C Shell version 2.7 (from Beckemeyer Software) as my CLI. I also use the Beckemeyer C Tools and the Beckemeyer MAKE program as part of my development environment.

The LC5 Market

Who is the LC5 compiler targeted towards? Well, the sheer size of the compiler tends to encourage the use of a hard disk drive, but HiSoft has adapted the LC5 Installation for use with dual double sided double density floppy based Ataris. LC5 will compile in a 1/2 megabyte system but once again you lose features. So, you should have at least one megabyte of RAM and two ds/dd floppies, while the LC5 compiler really demands a hard disk drive. The total LC5 package uses over seven (7) megabytes of hard disk space when fully installed with all of its tools! Atari 520ST users can not compile from within the LC5 editor for example. At a USA mail order price of almost $200 (though Joppa Computers was selling it for $150) LC5 is one of the more expensive compilers available for the ST.

The LC5 Package

The LC5 Package consists of the LC5 Manuals, an Installation Guide, and the LC5 floppies as well as the registration card and various advertisements from HiSoft.

The Manuals

The LC5 package consists of three spiral bound manuals totalling XXXX pages. The first manual is a compiler operation manual which describes the LC5 Tools ( the full screen editor, the WERCS resource editor, the MONSTC debugger, and the compiler ). The second manual documents the Standard UNIX Library as implemented in the LC5 package. The third manual documents Atari ST specific functions such as the AES and VDI functions. The manuals document the various ST specific header files as well as all of the functions in the LC5 libraries. Some functions have code fragments documenting their use. The Manual a separate index in each Volume. I have found the index to be helpful in locating various Library functions and compiler options.


I received the Version 5 First Edition March 1990 Volume I manual with my compiler. Volume I includes a Table Of Contents consisting of an Introduction, EdC, LC, CLink, Batcher, WERCS, MonST2C, ASM, GO, The Lattice C 5 Tools. There are fourteen Appendices covering compiler errors, compiler implementation, the assembler, GEM resource files, the libraries, and other compiler functions.

CHAPTER ONE is the introduction to the Lattice C. There are three Lessons in using the LC compiler illustrated with screen shots. Chapter One contains a Hints and Tips to help you get the most out of the LC5 package.

CHAPTER TWO describes the usage of the EdC Screen Editor. EdC is a proprietary editor for the LC5 package which is fully GEM based. EdC supports up to four open GEM windows. EdC allows the four windows to be tiled in four different ways. My favorite is to have them tiled vertically so that the title bar of each window is visible. EdC has complete Search and Replace, GoTo, and Find functions. EdC has autoindenting of lines as well as braces matching. EdC can compile the source code. All of compiler option switches are available through a Menu Bar from within EdC.

CHAPTER THREE descibes the LC5 compiler operation. One uinque feature of the LC5 compiler is the use of pre-compiled header files. Header files are ASCII text files which contain constants and external variable declarations. Header files are generally included in your C cource code files by use of the “#include” preprocessor operator. LC5 allows you to precompile these header files so that they are smaller then the normal ASCII files and take less time to compile. All of the LC5 precompiled header files are contained as normal uncompiled ASCII files in a separate folder named “headers”. The LC5 Floppies

CHAPTER FOUR descibes the LC5 linker “CLINK”. Clink may be evoked from “EDC” or directly from the GEM Desktop or from “Batcher” program.

CHAPTER FIVE describes the HiSoft “Batcher” command line interpreter program. A CLI program replaces the standard GEM desktop and uses either MSDOS style or UNIX style commands. Batcher is modelled after the IBM MSDOS CLI and uses DIR to list the directopy, COPY to copy files and other DOS style commands. All of the LC5 compiler stages may be run from Batcher.

CHAPTER SIX is the WERCS REsource Editor. A resource editor is a program which constructs GEM objects. A dialog box is a typical GEM object. Other objects are text boxes, buttons, and radio keys. WERCS will constuct GEM RSC files for C as well as other ST languages. WERCS has several unique features. WERCS has an Image/Icon Editor for constructing bit mapped graphics. Wimage is used to convert Neochrome or DEGAS Elite files into WERCS RSC Images. WERCS also has a TEST mode which allows you to test the operation of your dialog boxes and buttons.

CHAPTER SEVEN covers the MonST2C binary debugger. MonST2C is a low level debugger which requires familarity of the Motorola 68000 assembly language. MonST2C displays several one of which is the C source code file, another is of the binary listing. You are single stepped through the C source file, but if you which to set breakpoint, change C variable values, etc. you must modify them through their binary addresses. This requires a knowledge of the Motorola 68000 assembly language.

CHAPTER EIGHT is for the LC5 Assembler. ASM is a full macro assembly language assembler. HiSoft recommends purchasing their DevpacST2 if you plan to develope assembly language source code. Chapter Eight describes the operation of ASM but does not describe the implmentation of the ASM assembler. thus, it assumes that you already know how to program in assembly language, or that you have their DeVpacST2 package.

Chapter Nine covers the Global Optimiser GO which is optional run after LC1 and before the Clink linker/loader. GO can optimise your code for either smaller code or for faster execution.

CHAPTER TEN covers the other LC5 Tools such as their ’hramdsk’ reset-proof ram disk. Lcompact is a tool which precompiles a standard ASCII UNIX header file that is processed more quickly by the LC5 preprocessor. Recompilation is one way, thus you should save your original ASCII header files for later modification. Other Chapter Ten tools are for various object files. Wconvert convert older Digital Research or Kuma Resource Construction Set resource files into WERCS RSC files. Wimage converts Neochrome and DEGAS Elite graphics into WERCS images.

LC5 comes on seven (7) double sided double density 80 track 9 sector 3.5“ TOS floppies. As such, it is the largest C compiler package available for the ST. As a comparison, the latest Prospero C compiler is on three SINGLE sided double density floppies, while the Mark Williams Version 3 comes on YY double sided double density floppies. Rumor has it the the German Turbo C compiler is on five double sided double density floppies, although I can’t verify this. The importance of the number of floppies is that the compiler has more tools and larger libraries with more floppies. HiSoft has an additional nice touch in that the floppies are stored in a HiSoft Disk Jacket which has a hard cover.

Volume II covers the standard UNIX style libraries. functions such as fopen, fclose, printf, and scanf are documented in this manual.

Volume III covers the Atari ST specific AES/VDI libraries. Functions such as form_do, obj_draw, wind_set are documented in this manual.

The LC5 Compiler

The LC5 compiler is a two stage compiler with an optional final global optimizer. LC.PRG is the version of the LC5 compiler which incorporates a full screen editor. You can develop your code from within LC5.PRG and then compile it while running the editor. The LC5 editor allows up to four windows to be open simultaneously.



WERCS is the HiSoft resource construction set editor. I originally purchased WERCS from MIchtron over two years ago and have found it to be one of the best RCS tools available. WERCS is used to build RSC files for use in C and other languages. The WERCS manual is incorporated in the LC5 Volume I manual. WERCS has several nice features including the ability to include DEGAS and NEOCHROME pictures as icons within your RSC file. Another nice feature is the TEST mode where you can test your RSC file from within WERCS and see the return values of various objects. WERCS is a GEM program.


MONSTC is the Hisoft binary level debugger for the LC5 package. MONSTC is based upon the original MONST assembly language debugger. MONSTC has been modified to display the C source code in one window but you manipulate the variables at object code level. You should be familiar with the Motorola 68000 instruction set to fully utilise this debugger. Given that it is a binary (and not source) code debugger it is a very complete tool.


GENST is the assembler supplied with the HiSoft DevpacST2 assembler. GENST generates binary files in GST-format which can be linked with the LinkST linker included with the LC5 compiler. LinkST will link only GST-format files, thus you would need to compile your C cource so that GST-format binary files are built.


BATCHER is a very limited MSDOS style shell which allows you to run the LC5 compiler and editor interactively. Unfortunately MSDOS is the MAJOR reason why I don’t own an IBM PC and thus I haven’t used BATCHER. It may be of interest to Atari 520ST users as it allows you to use the LC5 package with only 1/2 meg of RAM by running each phase of the compiler from the shell.


LC5 comes with a batch process installation program on Disk 2. You are prompted for the level of installation desired allowing LC5 to be installed on machines from the Atari 520ST to a full blown Mega ST4 with hard drives. I have installed LC5 on my Mega ST4 with TOS1.4 and the FAST TECHNOLOGY TURBO- 16 board as well as a 130 megabyte hard drive (from ABCO COMPUTERS) system. Installation takes about 20 minutes for a full blown seven megabyte system!! In fact, several of the LC5 Libraries are stored in compressed format so as to reduce the number of floppies. Without the compression, the LC5 package might easily consist of 10 floppies!! Installation consists of answering several system configuration questions such as do you wish to install a complete or just a partial system, and then where the LC5 package is to be installed. After you answer the initial prompts you simply insert the correct floppy as prompted on the Atari ST monitor. The Installation program runs in medium and high resolutions.

ANSI Compatibility

As mentioned previously the only feature missing from LC5 is trigraphs. A trigraph is a three character sequence used to represent several ASCII characters not found in other languages. The following is from the ANSI Standard: Trigraph Sequences

All occurrences in a source code file of the following sequences of three characters (called trigraph sequences) are replaced with the corresponding single character:

         ??=             #
         ??(             [
         ??/             \
         ??)             ]
         ??’             ^
         ??<             {
         ??>             }
         ??-             ~

No other trigraph sequences exist. Each ? that does not begin one of the trigraphs listed above is not changed.

The following information is from the ANSI RATIONALE and describes why trigraphs were introduced. Trigraph sequences

Trigraph sequences have been introduced as alternate spellings of some characters to allow the implementation of C in character sets which do not provide a sufficient number of non- alphabetic graphics.

Implementations are required to support these alternate spellings, even if the character set in use is ASCII, in order to allow transportation of code from system which must use trigraphs.

The ANSI RATIONALE goes on in detail explaining why trigraphs were introduced, but stated basically some computer terminals lack the TILDE characters and thus another method of representing the TILDE character is required for those machines. The Atari ST has all of the required keys and thus does not require the trigraphs. But, HiSoft should implement trigraphs as soon as possible simply because the ANSI Standard requires it!!


LC5 has the BEST and most complete library available for the ST (even better then the Turbo C compiler from Germany!). I will document in future columns which are the best and most novel library functions and how to use them. Briefly though there are several. First, LC5 has the ability to generate code to run on ANY Motorola 68000 processor from the 68000 (used in the ST line of computers) through to the 68030 (used in the TT computers). Also, LC5 has implemented code for all of the TOS 1.4 and beyond functions. One nice touch is the extended file selector function introduced in TOS 1.4. The extended file selector displays a message above the File Selector Dialog Box (i.e. Save FileName ). LC5’s version will detect the TOS version at runtime, and will automatically display an additional dialog box above the File Selector Dialog Box when run on pre- TOS1.4 machines. Thus, the developer has access to the latest file selector, and LC5 generates code which runs the same on pre- TOS1.4 machines. All this without additional work from the LC5 user!!

Another great feature of the LC5 package is the ability to compile programs which can detect if they are run as a DA, as a GEM program or even as an AUTO folder program. I do not know of any other ST compiler with this feature!! So, now you can write your programs as GEM programs and then just rename them to ”.ACC“ and they can be run as a DA. LC5 maintains an external variable which contains the state of the program (DA, GEM, or AUTO folder program) and can be used by your code. LC5 even includes a small sample program showing how to use this feature. LC5 declares an external variable which is set to indicate the type of program at runtime. A valuable tool for ST programmers!!


Lattice C Version 5 has several glaring omissions which almost overwhelm its otherwise fantastic features. First, LC5 does not have an integrated MAKE utility. Second, LC5 does not have a source code debugger. Third, LC5 does not have a UNIX style shell. Fourth, LC5 has a serious bug in the editor/compiler which renders it useless for GEM programming. I will describe each miss next.

MAKE is a UNIX derived program. Make uses the timestamp of files to determine which files need to be recompiled to regenerate the final executable program. MAKE uses a file called the ’Makefile’ to describe the relationship between the source code files and the executable files. A ’Makefile’ must be constructed for each project, but there are several public domain UNIX derived Makefile generators which can help automate the construction of a project specific Makefile. Once a Makefile is finished you simply say ’make’ and the MAKE program will recompile and/or link only those files which have changed since the last make. This simplifies the development process and allows you to develop smaller source code files. Additionally, MAKE can be used to generate other targets besides programs. I routinely use MAKE on UNIX to format and printout documents which might need to be processed by ’troff’ and ’tbl’ before printing. So, MAKE can be used to manage any project based on the timestamp of files. Not having MAKE with LC5 makes developing large projects harder and more time consuming. LC5 has a limited Linking feature which allows you to use a Link Control File, but as this only tells the compiler which files need to be linked to form the executable, it is less useful than MAKE. The Link Control File mechanism also does not recompile the source, it only links the binaries together to form the executable.

Lattice C Version 5 does not have a source code level debugger. LC5 instead offers the MONSTC debugger which is heavily based upon the HiSoft MONST assembly language debugger. MONSTC has been modified to display a window with the C source code but you can not modify C variables. You step through the assembly language window instead. The value of a real source code debugger is once again demonstrated with the UNIX X WINDOWS ’cdb’ source code debugger. In it you can examine and change any C variable, single step through your C statements, set breakpoints (C statements to stop program execution) and set levels of debugging traces. All of these features reduce the amount of debugging time. Without such a debugger the programmer is reduced to using the primitive mechanism of inserting debugging statements (i.e. printf(stderr, ”This is an error.\n“); ) in the actual source code. Obviously this is error prone and time consuming. LC5 needs a full C source code debugger as soon as possible!

Lattice C does not offer a UNIX shell as an alternative to compiling from the GEM desktop. LC5 does offer a MSDOS shell called BATCHER but as I intensely dislike MSDOS (that being the biggest reason why I still own my Atari ST) I refuse to use it. A UNIX shell would allow you full use of a MAKE program, but since LC5 doesn’t have a MAKE program, the lack of a UNIX shell is less important. Also, since the TOS is a single tasking operating system, a UNIX shell is less useful in any case. The biggest power of a UNIX shell lies in its ability to ’pipe’ output from one program into the input of a subsequent program. Thus you could pipe a directory listing into a printing program under UNIX. Since TOS is single tasking such an operation usually involves creating temporary files and thus is slower. Still, a UNIX shell would be a nice feature.

Finally, the worst problem with Lattice C Version 5 is an actual bug in the LC5 Editor/Compiler. LC5 has a version of the the first phase of the compiler which loads the LC5 Editor. You can then compile from within the Editor. A normal development environment on a hard disk consists of many different directories (folders to STers). One such folder contains the LC5 binary executable files (which I call H:\LC\BIN). Other folders contain the LC5 Library and Header Files. And finally, the source code for a project is in its own folder (for ease of development and for backup). I use many different folders for my source code. The bug rears its ugly head because the Editor does not maintain the paths properly. One feature of the Editor is that you can compile and RUN your program from within the Editor. This is really handy when your program has many different source code files as you can have up to four files open simultaneously. The bug is that when you execute your program from within the Editor, the Editor uses its PATH as the current working directory of your program. Thus, if you write a GEM program which loads a RSC file in the same folder as the program’s executable, it will fail when run from within the Editor but will run properly from the GEM desktop!! This is because the Editor uses its PATH to open the RSC file. The following documents the bug:

 H:\LC\BIN\LC.PRG                  -
  the folder/executable for the Editor/compiler
 G:\SRC\SAMPLE\sample.c    -  a sample C GEM program
 G:\SRC\SAMPLE\sample.rsc  -  a sample C GEM Resource File
 /* sample.c */
 . other program code
         rsrc_load(”sample.rsc“ ); /* load the RSC file into memory */
 /* end of sample.c */

This program will fail to locate the ”sample.rsc“ file if run from within the LC5 Editor but operates correctly from the Desktop. If you copy the RSC file to the same folder as the Editor the program will run properly from within the Editor as well. This has caused some LC5 users to develop ALL of their projects from within the Editor’s folder!! This is undesirable because you can’t separate your various projects and you may delete files which you shouldn’t. This is a serious bug which HiSoft is aware of but hasn’t fixed yet. This bug occurs whenever you try to open any file from within your program.


I recommend the Lattice C Version 5 compiler in spite of its lack of a source code bugger and in spite of the editor bug simply because it is an ANSI C compiler and because of the strength of its libraries. Also, I have found Alex Kieran of HiSoft to be a valuable resource. I have written two letters to Hisoft documenting my findings and have received prompt replies from Alex Kieran personally. I find that HiSoft has excellent support and I have great hopes that they will soon release a Source Code Debugger as well as fix the Editor bug. I find that the WERCS RSC Editor is very complete and bug free. The LC5 Library is simply superb.

I switched from the Mark Williams C compiler (which does have a source code debugger) to the LC5 compiler mainly because I needed an ANSI compatible compiler. If that is your requirement then I highly recommend the LC5 package from HiSoft.

Next week, I will start a series of articles showing how I ported a C Printing/Formatting program to the ST first as a TOS Take Parameters (TTP) program, and then in later articles as a GEM based program and finally as a Desktop Accessory/GEM program utilizing the auto- detecting feature of LC5. In the process I will describe some of the many LC5 Library functions which make the LC5 so fun to use. Future columns will show how I use the Beckemyer Tools to enhance the development environment by adding a true UNIX C Shell, MAKE , and other UNIX Tools. Later, I will show how the Beckmeyer MultiTasking C Shell can be used with the Lattice C compiler. I will first document various Libraru functions unique to LC5 and show how to use them. I will work you through the development of a GEM RSC file and present a skelton C file for use with LC5. Hopefully I will be able to show just how valuable the LC5 package is through an actual program.

R. Covert
Aus:ACE 50 /, Seite


Copyright-Bestimmungen: siehe Über diese Seite