What is qdos-gcc ?
This is a gcc cross-compiler for Linux (should work under other UNICES as well) which is able to generate QDOS/SMS executables. Only the cc front-end (gcc), the pre-processor (cpp) and the compiler phase (cc1) are actually gcc-specific. Some C68 utilities (as68, ld and slb) are still used by qdos-gcc so to generate the final QDOS/SMS binaries. The libraries that qdos-gcc may use are all the existing (unmodified) C68 libraries, but the main library (libc_a) had to be adapted slightly so that its (excellent and fast) math routines could be used by qdos-gcc.
The qdos-gcc project is maintained by:
In fact this project arose from the many messages exchanged through the ql-users mailing list. Richard and I both agreed (this is so rare we agree on something that this must indeed be noticed ;-) that QDOS/SMS was lacking a C/C++ compiler able to generate really fast code; this point of view was warmly seconded by a few other well known QLers. A few weeks after the messages were exchanged, Richard sent us the first gcc patch: qdos-gcc was born !
Why should I use qdos-gcc ?
The QDOS/SMS systems already have an excellent C compiler: C68. This compiler is small (c68, the compiler phase, is less than 140Kb), ANSI C compliant, fast, and generates small and reasonably fast code.
On the other hand, most of the other operating systems have got gcc which is big (cc1, the compiler phase, is over 1.5Mb) but generates much faster code and can deal with C++, Objective C and Java as well (qdos-gcc is not yet ready to deal with these languages though).
Another thing to consider is that qdos-gcc being a cross-compiler, you can take benefit of all UNIX utilities (such as GNU make, autogen, autoconf and automake which are used in most major projects) that have not (yet) been ported to QDOS/SMS. Porting a C-written software to QDOS/SMS is therefore made easier (no more manual generation/editing of the makefile/config.h/etc... files !).
The last argument in favour of a cross-compiler is the compiling speed benefit for those who are running this cross-compiler on a hardware which is faster than their QL-compatible computer/QL emulator (compiling the whole libc.a on a Core-i5 at 4.6GHz only takes 7 seconds... and that's only using one core among four, since the library can't be compiled with "make -j4").
And what speed gain over c68 compiled software can I expect ?
This is of course dependant on the compiled software and on the plateform you run it on... Here are some results of tests I made on a QXL (with a full blown 68040):
OK, you convinced me ! Now how to install qdos-gcc ?
The prerequisit is to have a running Linux (or UNIX) system with a shell account, GNU make, sh (bash2 preferred), tar (bzip2 aware), bzip2, and a native gcc v2.95/2.96 compiler with associated utilities (as, ld, etc..., usualy known as "binutils") and development libraries. Note that the sources for gcc v2.95 will fail to compile with v3 and newer gcc versions (but most Linux distributions do provide older gcc compilers such as v2.96 or v3.3.6, often in a "contrib" or extended packages repository).
$ gcc --version
You should get v2.95.x or v2.96 as a reply. If you get v3 or larger versions, your default compiler is not properly configured: check the documentation for your distribution to learn how to choose the right compiler (for example, in Mandriva and its clones, it's done with "update-alternatives --config gcc").
$ mkdir /usr/src/qdos $ cd /usr/src/qdos $ tar xjf ~/gcc-core-2.95.3.tar.bz2 $ tar xjf ~/qdos-gcc-utils-v2.tar.bz2 $ tar xjf ~/libc-4.24.5.tar.bz2
$ cd gcc-2.95.3 $ bzcat ~/qdos-gcc-diff-091000.bz2 | patch -p1 -s $ bzcat ~/gcc-2.95.3-bufixes.patch.bz2 | patch -p1 -s (*) $ cd ..
(*) Optional.
$ cd qdos-gcc-utils $ make $ make install $ cd ..
$ cd libc-4.24.5 $ make install-includes $ cd ..
$ mkdir build-qdos-gcc $ cd build-qdos-gcc $ ../gcc-2.95.3/configure --target=qdos $ make $ make install $ cd ..
$ ./qdos-gcc-utils/scripts/post-gcc-install
$ cd libc-4.24.5 $ export PATH=/usr/local/qdos/bin:$PATH (*) $ make install $ cd ..
(*) This line ensures that qdos-gcc will find the proper cpp executable: modern cpp's may fail to produce a gcc-v2.95-compatible output, which would cause a compilation failure...
That's it ! qdos-gcc is installed and ready... You will find qdos-gcc utilities and scripts into /usr/local/qdos/bin, while the C68 include files reside in /usr/local/qdos/include and the C68 libraries into /usr/local/qdos/lib. The qdos-gcc compiler itself resides in /usr/local/lib/gcc-lib/qdos/2.95.3 and some useful soft links are setup into /usr/local/bin (which should be part of your shell PATH variable). Note that when compiling programs using qdos-gcc, you must add a -lgcc option to the ld parameter list.
Known bugs and incompatibilities:
Bugs (note: these were the bugs present in qdos-gcc v2.95.2; I didn't check if they are still present in v2.95.3):
gcc v2.95 sometimes "forgets" that the stack has been tidyied up on return of a self-tydying math function. This results in a crash if the program was compiled with the -fomit-frame-pointer optimisation flag. There is a work-around for this bug implemented into both qdos-gcc and libc.a v4.24.5 though: libc.a implements new math functions that don't tidy up the stack before returning, and qdos-gcc makes use of these functions by default (it is therefore possible to use the -fomit-frame-pointer optimisation with qdos-gcc when using libc.a v4.24.5). If you want qdos-gcc to make use of the old C68 libc_a integer math functions, then you must specify -mc68lib -fno-omit-frame-pointer into the gcc command line.
cpp fails to expand properly some macros (a spurious space is pre-pended to the expanded macro), e.g.:
#define LN l move.LN d0,d1Expands as:
move. l d0,d1 (an extraneous space is put before the l)
The example above corresponds to a pre-processed assembler source and this is where it may be problematic (well, it actually was for libc.a sources !). C sources should not be affected...
A problem with programs using the libcurses library was reported by Jonathan Hudson (spurious lines in screen output): the reason for this bug is currently unknown.
They are detailed into the qdos/c68.interoperability file of the patched gcc-core source tree. In short, they deal with:
These incompatibilities should not be a problem for the application level programmer since well written software don't rely on such features. This could however have an impact on some (assembly written) libraries...