History of our Compilers
Main Menu |
C68 for QDOS |
The QDOS saga
The next major thrust came about with the release of C68 on the QDOS platform. QDOS
is the operating system used by the Sinclair QL and is highly under-rated. It has
been ported to a number of alternative hardware platforms and has a small but loyal
following. It is still one of my favourite operating systems.
A QL software house called PDQL had decided that it would like to bring to the market a
new C compiler, and gave it the working name of PDQ C. This was to be
a full C development environment right from the editor through to the
required runtime libraries and was intended to act as replacement
for QLC (a QL version of Lattice C) which by then was no longer
being actively marketed or supported on the QL. PDQL started
advertising PDQ C product from late 1989. Although this product was
never made generally available in the marketplace, it was not
completely "vapourware". PDQ C was in fact ready by about
December 1989 if licensing problems could have been sorted out.
The work to produce PDQ C had been done by Jeremy Allison. He
had done this out of interest, and not as a result of a
particular commission from PDQL to produce such a product. The
reason that there were problems with the licensing was that the
PDQ C product was based on Lattice C. PDQL never proved to the
satisfaction of Jeremy Allison that they had the rights to
distribute a product containing Lattice C, so the final product
was never passed to PDQL.
This port of Lattice C was interesting in that it was done by
writing an emulator for the QL that allowed it to emulate part
of the Atari ST operating system. The details do not matter
too much (if you are interested I have written a separate
description of this emulator), but
suffice to say that it:
The real improvement that PDQ C was going to have over QLC (and
the area needing the most work) was that the C library had been
extensively re-written. Some of the implications of this
improvement in the C library were:
- Was efficient
- Allowed the Atari ST version of Lattice C to run on
the QL. This was version 3.04 of Lattice C which is
a "bug-cleared" version of the Lattice C v3.02 that
Metacomco C was based on (which will be refered to as
QLC from now on).
I got involved late in the project to help with the testing
and the last stage of work on the libraries. The development
had by now progressed until it was largely completed.
Unfortunately, as mentioned above, PDQL never completed the
necessary licensing arrangements for Lattice C, and eventually
PDQL went into receivership. Jeremy decided to wash
his hands of the PDQC development and put the work he had done
to date into the Public Domain.
- It was clear of the bugs that had plagued the QLC
- The standard C file handling routines were enhanced
to support Toolkit 2 directories.
- Full support for all QDOS trap and vector calls.
This meant that there was a largely complete C system, but that it depended on a core
component - the Lattice C compiler - that was not public domain., and this was where
C68 came into the picture. It was a compiler for which the source was publicly
available and that could be freely distributed. This could replace the
Lattice C component of PDQC. Lattic C also had a built in pre-processor facility, and
for this the public domain DECUS pre-processor (later the GNU one replaced DECUS) was
ported to do the job. The product was released as "C68 for QDOS". This has become
the dominant C compiler within the QDOS marketplace - and in fact a number of people
have credited the arrival of C68 on the QDOS scene as being one of the factors that
has allowed QDOS to survive as it allowed quality software to easily be ported from
many other environments.
The "C68 for QDOS" product has gone through a number of major releases, and minor
upgrades between those releases. The idea was that we changed the major version
number when there might be object code incompatibilities, and the minor number was
incremented for less severe changes. The major releases broke down as follows:
- Release 1.xx series was the initial release.
This probably should have been called a beta release as at this stage
as although we had a working product there were still many problems.
In particular this applied to the libraries
as in many cases we had objects to which we did not have sources - somewhere
along the line they had got lost! All I can say is that the product was already
probably comparable in quality to the commercial offerings and it was free.
- Release 2.xx series was much more robust. By this stage we had
source to everything which was a major step forward. We also developed utilities
such as a librarian to help with maintenance of object libraries.
- Release 3.xx series was when we switched the floating point support
from using the Motorola Fast Floating Point format to using IEEE. Also during
this release we upgraded the library support to ensure that as well as all the
ANSI and Unix C interfaces, we also provide access from the C level to all the
native operating systems calls available in QDOS.
- Release 4.xx series was when we finally got to ANSI compliance.
Both the compiler and libraries were bought in step.
The above program was a major driving force for developments in the compiler itself.
It gave both an incentive to make improvements, and also an eager user population
willing to try things out. The major developments that took place in the compiler
program itself during this phase is give below. Some developments were in the
front-end syntax analysis phase of the compiler and this became available in all
variants with no further work, while others were in the code generation side and
thus specific to the target processor (which for this period was mainly the 68000 family):
By late 1994 the QDOS release of C68 was stable and all the immediate
concerns had been addressed. While work has continued within the
QDOS implementation it has tended to focus on aspects of the QDOS
development system that do not concern the compiler itself. However
any improvements to the compiler are fed back into the QDOS based
releases very rapidly as it provides a good basis for us to get early
feedback on any new features.
- Floating point support improved.
The development of support for IEEE
floating point in place of the MFFP support that was in earlier releases of C68.
This support has gone through two major phases; the first being to add IEEE
support purely within software, and the next (relatively recently) to add the
option to generate code that calls on hardware FPU directly.
- Multiple processor support improved.
You can now specify when you
build a version of the compiler that you want support for more than one target
processor built in (previously there was a choice, but you could only chose one).
To complement this you can specify which one you want as the default, and there
are runtime options to pick any alternatives.
- Multiple assembler support improved.
Rather like the multiple processor
support you can build in support for many assemblers; specify the default one
for each target processor type, and also specify any of those you added support
for by runtime parameters.
- The warning system has dramatically improved. Every time we made a mistake in
a program that although syntactically correct may well have not been what
the programmer meant (such as use of = instead of ==) we looked at whether
the compiler could have warned us about it. After a while we also started
looking consciously at the warning messages output by other compilers and by
tools such as LINT to see if we could build in similar capabilities. The result
is a very comprehensive warning system that has been graduated to allow you
to select any level of 'pedanticity' that you like.
- Major improvements in the optimisation.
The code generated by the latest QDOS releases can be anything up to 25 per cent
smaller than was the case for the first release. It is noticeable that although
the compiler has grown dramatically in capability over this period, it has not
grown that much in size. In fact one of our criteria for a good
optimisation was that it should reduce the size of the existing code in the
compiler by enough to offset the additional code that we had to include to
implement the new optimisation.
It was about this time that the
Psion 3a and CPOC started to play
its role in the story.
Main Menu |
C68 for QDOS |