[Coco] NitrOS-9 EOU Beta 6 released

Jeff Teunissen deek at d2dc.net
Fri Dec 25 21:04:03 EST 2020

Sorry for the long message, I didn't have time to make it shorter. :)

DCC is a project to incrementally obsolete the Tandy C compiler,
supplanting each part with components that are better than what we had
before. Initially, I expected to individually replace the components,
so the C preprocessor would replace c.prep, the compiler would replace
c.comp, and so on...but I ran into a bug in one of my versions once
that resulted in a compiler that could no longer compile itself, and I
realized I should instead build a compiler toolchain that would be
better than the Tandy stuff, but still be able to completely coexist
with the original compiler. Thus, DCC.

The included C preprocessor, dcpp, is much more compatible with ANSI/ISO C.
It already supported some modern C preprocessor features like:
* Line continuation using \<newline>
* BCPL/C++-style "//" comments (I love these)
* #if syntax in addition to K&R #ifdef/ifndef/etc., so you can do more
complex #if A && (B || C) constructs
* __FILE__, __LINE__ macros (__FILE__ was a bit broken, but I fixed it)
Some features I have added:
* ANSI/ISO token pasting using ## -- that is, inside a macro FOO(a), a
## _b -> <value of a>_b
* ANSI/ISO stringizing using # -- inside a macro FOO(a), #a is
replaced with string literal "value of a"
* ANSI/ISO conforming "null" directive, so you don't have "illegal #"
warnings for empty # lines
* A working #line directive, so errors in generated code can be traced
back to their original source.
* GCC-style #warn and #error directives, for synthesizing errors and
warnings to tell the programmer things.
* Pre-defined macros for OS9, _OS9, __mc6809__ and __DCC__ to enable
more portability.
* It parses directives almost exactly like an ANSI/ISO C preprocessor
would, so it doesn't replace macro args inside strings, and directives
can contain comments (which will always be hidden from the compiler
entirely). In case this _isn't_ what you want, you can disable it by
passing -k to dcc when you compile.

It's also smaller than, has higher limits than, and runs
_significantly_ faster than c_prep. Like, almost twice as fast.

The compiler proper, dcc68, is basically equivalent to the Level II
"c.comp" compiler. It's derived from the source code of the c^3
project, which is an OS-9 C compiler that produces code that works (I
think...), but has a very different calling convention from the
Microware/Tandy release of the McCosh C compiler. As a result of this
change in calling conventions, if you tried to use _any_ of our old C
libraries your program would explode into a million pieces if you
tried to run it. Not good. :) Using the disassembled/decompiled code
we know as the "Climax" compiler, I managed to figure out the cause of
the different calling convention and restore the one we're used to. It
took a while, but now it works almost exactly like the Tandy compiler
except it makes better code.

The big feature in dcc68 was kept from c^3, it's "register contents
tracking". The McCosh (Tandy) compiler uses D and X for scratch
registers, so every time it wants to check a value for something, it
first loads it into D (or X, if it's a pointer) and does the
comparison. The next thing that needs checking, the same thing happens
-- the value gets loaded into D or X, the comparison gets done, etc.
Register contents tracking lets the compiler know when the expression
it's testing is the same as the one it just tested, so it gets to
avoid loading that value from memory all over again, which saves bytes
and cycles.

The optimizer, dco68, is equivalent to c.opt, only it does a better
job, it's programmable, and it has the (optional) ability to do
different optimizations for Level 1 and Level 2. It's based on the
optimizer from the c^3 project, but that program didn't actually have
the ability to do the "peephole" optimizations that c.opt does. I
added that ability back in and made it programmable, so dco68 actually
reads data files which describe the types of optimizations it can do,
from /DD/Lib/level1.patterns and /DD/Lib/level2.patterns.

Because of this, there's no need to use the "CNoY" program written by
Mike Knudsen in the 90s, because now the optimizer can apply that
optimization itself, converting Y-based indexed addressing into
absolute addressing for Level 2 systems -- just pass -2 on the dcc
command line and get faster programs that require Level 2.

The compiler executive, dcc (the thing you run unless you have some
special needs), is based on Carl Kreider's CC version 2.2, but with
special support for other parts of the DCC "system". It's also
prettier and can compile on Linux like the rest of my tools.

That's the other big thing -- the same tools run on both OS-9 and
Linux (and probably Mac, and maybe cygwin but I haven't tried it).
Once I can integrate David Breeding's R63 and a working-from-source
RLINK into DCC, you should be able to fully compile OS-9 C programs
and expect them to just work on a CoCo or other 6x09 OS-9 machines.

On Thu, Dec 24, 2020 at 10:48 PM Allen Huffman <alsplace at pobox.com> wrote:
> On Dec 24, 2020, at 9:32 PM, L. Curtis Boyle <curtisboyle at sasktel.net> wrote:
> >
> > New DCC C compiler, that compiles programs to run a little fast and smaller than before
> what is the based on?
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco

More information about the Coco mailing list