LATTICE
C
Independent Software Vendors (ISVs) who bought the Atari development
package will never be given a bug free update of the software.
That's official. And it's not good news for those struggling with
the DRI compiler's 'idiosyncrasies'. So when Metacomco announced
that they were to produce a version of the Lattice C compiler, a
compiler that has proved popular on other machines, many programmers
looked forward to it arriving. It is now here, and I have been
giving it a good test, compiling over half a megabyte of source code
with it. It has not exactly been trouble free, but it is smoothing
out.
THE COMPILER
Lattice C is a very complete compiler, conforming
very tightly to the K&R specification (see last issue for
details), and giving the option of various useful extensions. The
variations from K&R are so slight that you have to be very
specialized to notice, but the extras include nested comments
(useful for commenting out large blocks of code), character
constants can be defined in hexadecimal (i.e. not only octal like
'/40', but '/0x20' too), the searching of up to four other
(non-default) directories (paths for #include files, an optional
'post-pre-processor' file creation (a debugging aid) and the ability
to create either .O or .BIN binary files for the DRI LINK68 or GST
LINK linkers respectively (the latter is supplied in the package).
One problem with the Lattice compiler is that the
command line to start it (it is a .TTP file) is very long, and it is
therefore easy to make mistakes when you are typing it in for the
fiftieth time at three in the morning. (Hint: use a batch file.)
Metacomco are working on a GEM based 'command shell' similar to that
of GSTs that I reviewed in the last issue. This should help
somewhat, though a better editor than the ED program (reviewed in
issue 19) supplied may be needed to complete the package. Until such
time as it is available (it is about to be Beta tested as I write),
you must work from the desktop.
THE LIBRARIES
The standard library supplied in the package has
all the usual functions, and includes floating point maths and BIOS,
XBIOS and GEMDOS trap functions. The first release had a disastrous
bug which meant that few of the GEM calls operated correctly.
Metacomco soon realised this and fixed it, and this is where I found
one of the advantages of Lattice C over some others - the producers
are English. This has meant that when I have had a problem that
boils down to the compiler I can ask them for help. (I do not
however wish to encourage you to contact software houses every time
you have a problem as if everyone did so they would never get any
more programming done. If you do have a problem, check it very
thoroughly first and read ALL the manual twice. Only then should you
write to them with as much relevant detail as possible, perhaps
including a disk with all your files on it. If you waste their time
they will not be keen to help when you really DO have a problem.)
A GEM library with all the VDI and AES calls is
provided. The problem I found with this is that the five GEM arrays
through which parameters are passed are not actually globally
available, but are defined in the library. This means you cannot set
them up yourself and then call GEM, you must always use the standard
calls. This may be good for keeping to standards, but it will cause
problems for a few more advanced programmers.
THE LINKER
Lattice C is supplied with the linker produced by
another British company, GST. The linker is needed to convert the
binary files produced by the compiler into executable programs after
linking in functions used from the libraries. This is quite easy to
use, but again can have a fair sized command line. I did find one
slight area of incompatibility between the compiler and linker that
was not warned about in the manual. It occurs as the result of a
typing error in a source file. If you mistype a function name by
changing the case of a character, i.e. printf() and Printf( ), the
compiler, which is case dependant, creates two separate references.
The linker considers them the same though and considers the double
reference as an error, giving a vague 'error in binary file'
message. Tracking down the offending line is a slow process.
THE MANUAL
The manual is a thick book packed with all the
reference information you will need and more. Explanation of how to
use the editor, compiler and linker, comparison to K&R C,
full standard library function descriptions, an
explanation of the 68000 implementation, how the compiler optimises
certain things, run-time program structure, full error message
explanations, some example programs, and a standard and GEM function
list are all included. Again, this is not a tutorial, but a
reference manual, and most users will not understand everything they
read at first. As with all such things, experiments will teach you
much, and once experience is gained, a re-read of the manual will
reveal much more understanding. While generally very good, the
manual does have a few deficiencies. First, the message which
explains the 'error in binary file' problem is missing a line. As
well as being awkward for my problem, it could be an indicator for
other errors with text missing (I did not read them all!). Also the
simple listing of the library functions is very misleading, having
things like 'peek()' 'poke()' and 'int86()'. In C there is no peek
or poke, and int86 and others are there from the 8086 version of
Lattice. The detailed descriptions do reflect the libraries so a
check can be made. The implementation details are very useful,
especially as it reveals that the 'int' size is 32 bits (most others
use 16 on the Atari - this is where the WORD LONG BYTE portability
macros come in...). Also revealed is the fact that 32 bits are
always passed on the stack for each parameter of a function,
regardless of the parameter size. This means that even if you only
pass an eight bit byte (e.g. 'putch('a');'), 32 bits will still be
passed. This would normally be insignificant as the translation is
done automatically. GEM, TOS, and any other system calls you can
find all expect only 16 bits, and so an interface (the library
calls) must be used. Again this is something only the more advanced
will notice the effects of.
CONCLUSION
To conclude, Lattice C will satisfy the demands of
both novice and professional programmers. It may not be quite as
friendly as the more limited GST compiler, but its full capability
will probably make up for it. If you want a full C, this will give
you a good one.
EXTRAS REQUIRED
The problem that many programmers, professional or
not, will have is that to use GEM fully, a resource and icon editor
is needed to build the menus, dialogs and such like. Both GST and
Lattice lack these so you must buy them separately. Not so much of a
problem until you realise that only one has been available since the
ST was launched, the Digital Research version which has bugs. The
first alternative to come out will be that supplied with Megamax C
(which should be out by the time you read this - review coming
soon). This will take away many purchasers of the British Cs. I
personally hope a cheap Resource Construction Set is brought out
shortly to complement the UK software (GST are 'thinking' of doing
one).
Copyright 1986 Matthew Jones
top
