DRACO Compiler, by Gray Sage, its Author

Compilers and Programming Languages by Gray Sage
-----------------------------------

For the non-computer folks who might be reading this, a compiler, in
the computer world, is a special kind of program that reads in a human-
written form of a computer program and converts it to a form that the
CPU chip itself understands. The CPU does not directly understand the
things that humans like to use - it really only understands those huge
masses of random-looking zeros and ones. Only on the very first
computers (in the 1940's or so) did people actually do this job by
hand - they very quickly got tired of it and starting writing programs
to help them write programs. The fancy tools you see today, like plug-
ins, Visual Basic modules, etc., are really only the latest point on
this trend.

Writing compilers is probably a pretty strange hobby, but that hasn't
stopped me. Actually, calling compilers and programming languages a
hobby probably isn't really right. A better way to put it is that I'm
just more than usually stubborn and when I think I know a better way
to do something, I don't let little things like pointlessness get in
my way. So, if I don't like the programming languages available to me,
I see nothing wrong with creating a new one, even if no-one,
eventually not even me, will end up using it.

The first compiler I wrote, like many programmers who end up writing
such things, was done for a compiler-writing course I took in
university. Like most such things, it was terrible. However, since I
was already enjoying programming, and happened, due to circumstances,
to have lots of time to put into it, I had fun doing it.

Nothing much more happened for a couple of years, but I kept an
interest in programming languages and programming in general.
Eventually, I was taking a Master's Degree, and ended up designing a
programming language intended for Artificial Intelligence work. To
this day, I fail to understand why workers in that field insist on
saddling themselves with god-awful messes like LISP and Prolog. [At
this point I will quickly duck and hide, so that the fans of such
languages won't hit me with their cannons.] Anyway, since a couple of
professors in the department were involved with the Algol68 language,
that language had an influence on the language I designed. I called
the language ALAI (A Language for Artificial Intelligence - original
isn't it?), and it had reversed keywords like Algol68. ALAI was a huge
language, with pretty much every language feature ever invented in it.
My Master's paper, describing it informally, is a couple hundred pages
long.

After getting the degree, my supervisor decided he wanted me to
actually create the beast. So, he paid me to do that for a while. I
started out doing it in IBM 360 mainframe assembler language, but that
soon became too much of a chore. So, I decided that since there
weren't any really good tools around (I think AlgolW and Fortran were
the only other choices at the time, although there might have been an
early SNOBOL interpreter too), I should first produce a tool to help
me. I came up with a truly ugly programming language, which I called
QD, standing for Quick and Dirty, and proceeded to use AlgolW to write
a compiler for that. It worked, and there were at least two other
people besides myself that actually used QD.

The example QD code I found are the sources to another language I'll
be mentioning here. That is the Six compiler and the Fant interpreter,
both written in QD. Other than the truly ugly syntax for some things,
there are a couple of interesting points about QD. One is that the
language really didn't have any types. Unless specified with a
trailing '#' and length, everything is assumed to be a 4 byte integer.
It's like writing assembler code, in terms of type checking, but with
the constructs of a higher level language. That, and the QD compiler's
lack of a true tokenizer, were interesting experiments, but I wouldn't
recommend that anyone repeat them! The language was closely tied to
the IBM 360/370 architecture.

Here is a sample of QD code. The author of this code, the first 3
pages of the Fant interpreter listing, will presumeably be
appropriately embarrassed if he ever sees it. However, looking at the
listing for the Six compiler shows that I wasn't any better at the
time. So, when I start to get too snobbish about programming style,
just point me here!

The point behind QD was to implement ALAI. I started on that project,
but the general ugliness of things must have gotten me down, since I
then convinced my supervisor that producing another language, whose
compiler was to be written in QD, was a good idea. (I don't know how I
managed that!) This language was going to be much nicer to look at and
work with, but still wouldn't take long to implement, so it was to be
called QC, for Quick and Clean. So, I then went off and produced
another compiler that was closely tied to the IBM 360/370
architecture.

The QC sample here is from a full-screen single-player roleplaying
game that I wrote in QC. It was called DD (as in Dungeons and
Dragons), and the world-creation program for it was called DDSPEC. At
least I had discovered the joys of lower-case by then, and had figured
out a consistent indentation style. QC had some types, but inherited
some of the '#' syntax from QD.

My supervisor was not at all interested in me spending his money to
create yet another programming language (I don't recall if I was silly
enough to suggest it or not), so I got to work creating the ALAI
system, which was supposed to include both a compiler and an
interpreter, merged into one interactive system. That's a pretty tall
order for one slowly-learning grad student, so my supervisor
eventually gave up on me and I had to get a real job. As a further
example, here is what some ALAI code was supposed to look like.
Clearly, these samples were written before I had learned to indent. As
I mentioned above, ALAI had a ton of features in it, such as automatic
backtracking, built-in aggregate types like "bags", "lists", "tuples",
etc. evaluation of expressions built at run-time, a built-in object-
attribute-value database, etc.

Mentioned previously is the Six/Fant system. This was a system
designed for writing single-user adventure games. I wrote the compiler
and a friend wrote the interpreter for the virtual machine. I used the
system to write a version of the standard "Adventure". Others used it
to write a variety of adventure games. Basically, the Six language
(named from the six days of creation) was a fairly standard structured
programming language, with some special syntaxes added to aid in
constructing the world and the parsing setup. As usual, I have a small
sample of it. For those who might be interested, I have a full page on
the Six/Fant system, which includes the documentation and full sources
for 3 adventures.

There were of course a few problems with the Six language. One was
that, being written in QD, it was stuck on an IBM 360/370 running the
MTS (Michigan Terminal System) operating system. As far as I am aware,
no-one in the world runs that anymore. Another problem was that the
system had no linker, so the source for the entire adventure had to be
in one large file. A third problem was that the language only had file
scope and function scope. All verbs and their aliases were in the file
scope. So were the names of objects and their aliases. So, it was easy
to get symbol clashes. To work around that, I made all of the utility
functions and variables have names starting with an underscore.

Sometime around here I got my first home computer, which was an old
Exidy "Sorcerer", running CP/M. Clearly, it was time to stop writing
compilers for the mainframe, and write one for the Intel 8080 and the
Zilog Z80, and the CP/M operating system. The problem was that there
wasn't any existing compiler for CP/M - just interpreted BASIC and
assembler. Not wanting to let that stop me, I decided to just write a
compiler in itself, and worry about implementation details later. I
was at home when I was doing that (literally writing it out with pen
and paper), so I recall asking my mother what I should call this great
new language. She claims to not remember this, but one of us
remembered the nursery rhyme that ends in "and called it macaroni".
Well, macaroni doesn't make a very good name for a programming
language, but MAC can stand for "Microprocessor Algol Compiler", so
that was the name for my new language.

With the writing complete, it was time to implement it somehow. I had
just recently started using UNIX systems, on a DEC PDP-11/60 computer.
So, I typed the MAC sources in, translating to C as I went. I also had
the compiler emit simple PDP-11 instructions rather than Intel 8080
instructions. Eventually, with some help from a friend who wrote a
simple linker for me, I had it working. I discovered that the
PDP-11/60 didn't handle some stack operations the same as the
PDP-11/45, so I had to switch to the 11/45. That MAC compiler treated
the PDP-11 as a stack machine, essentially ignoring the registers for
most things. I then went back to the MAC sources for the MAC compiler,
which I had been updating, and now had a MAC compiler, written in MAC,
that I could run.

Following that, I changed the compiler to emit Intel 8080
instructions. I then had a compiler on UNIX that compiled MAC, and
emitted CP/M object files. Luckily, the mainframe downstairs had an 8"
floppy drive on one of its front end machines, so I could write the
resulting programs to it, and then take the floppy upstairs to where I
had my Sorcerer on a table in my office (by then I was working for the
Computing Science Department). It was a slow and painful way to get a
compiler working, but it actually went fairly well. Again, I
eventually ended up with a MAC compiler, which was able to compile
itself on CP/M. From then on, I was independent of any other computer
for my work.

Somewhere around then, I heard about Project MAC at MIT. Ack! They
stole my name! Well, they weren't going to change their name for me,
so I had to find a new one. I was chatting with friends one evening,
and it came up that a couple of programming languages had names
relating to celestial objects. One is the Algol family - there is the
star Algol, which is the dog-star, or the star of evil. Another, at
least according to the old TV series "Battlestar Galactica", is Cobol,
which was a planet in that series. So, with those precedents, I went
looking for a good name. Betelgeuse is far too long and hard to spell.
So, I ended up with 'Rigel'. The first version of the language was
missing a few features, like a full-strength type system. So, in the
belief that I would eventually remedy those problems, the existing
version became known as Tiny Rigel. That can be seen in the names of
the old versions of source files, headers, library files, etc. in a
'TR' prefix.

Naturally, someone else eventually came out with a programming
language named Rigel. I don't recall, but I think it was a database
language of some kind. So, I needed yet another name. Nothing
appropriate came up in star names, but the largest constellation in
the northern sky did catch my eye. So, my language became Draco, and
it has stayed that way since then. There is an ironic rightness to
that name, since Draco is a strongly typed language and it has been
called "Draconian" by some of its users.

I put a lot of effort into the CP/M Draco system. I ended up with a
very nice system, that likely could have been sold commercially if I
had any business sense. The first piece was the compiler, which
compiled in one pass, including register contents tracking, lots of
special cases, and a not bad peephole optimizer. There was also the
linker, which would operate in one pass if everything fit, and two
passes if the resulting program didn't fit in its buffer space
(remember that CP/M is limited to about 56K of usable space). The
linker would search libraries multiple times in a well-defined order
if needed, unlike the UNIX linkers which don't know how to do that.
The system also included my own assembler, disassembler, librarian and
cross-referencer. Also shipped with it were full run-time libraries, a
library of CRT routines that were configurable as to control codes
(like termcap or termlib in UNIX), and my own multi-buffer screen
editor (called Ded, for Draco editor). Last time I looked, all this
stuff, with comprehensive documentation, was still on the mirrors of
the old Simtel CP/M archives. My documentation was also published
(without even asking me!) in the McGraw-Hill book "Online Programming
Languages and Assemblers" edited by William J. Birnes, published in
1989. ISBN 0-07-005395-2

I did a lot of programming in Draco, asside from the stuff mentioned
above. One set of programs was an old Ultima-style system where people
could write role-playing games. CP/M didn't come with graphics by
default, but I had a CompuPro graphics board which I used to good
effect (it had the same graphics as the old Radio Shack Colour
Computers). I distributed Draco as shareware, and made something like
$1000 with it. I don't really know how many people used it, but I know
there were at least a dozen or so, since they sent me some of their
programs. I probably still have old letters with uncashed cheques or
money orders in them, since my policy was that I wouldn't cash them
until I had responded to the letter, and I am terrible at doing that!
I also did some contract work, a database system and a text formatting
system. For those who are curious, here (37.5K) is the full source for
the assembler.

Since most of the younger folks today have never even heard of CP/M,
which was a very small operating system (Control Program for
Microprocessors) from Digital Research, it is clear that I eventually
had to switch to something else. Like many other UNIX fans, I was
immediately struck by the multitasking, graphics, and shell abilities
of the then-new Commodore Amiga computer. It could multitask a full
GUI system in 256K of memory! It had advanced colour graphics and a
pair of custom processors! So, I bought one of the early ones (it
still works, and is hooked up to my TV set), and naturally decided to
port Draco to the Amiga. That was another cross-compiler exercise, but
in that case it was helped by having a serial link between my CP/M
computer and the A1000. Eventually I got that new version hosted on
the Amiga, and proceeded to do a lot of improvements, like adding IEEE
floating point, greatly improving the code generated, etc. It's still
basically the same compiler, however.

With that compiler (which was first done on the A1000 with two floppy
drives and 512K of RAM), I again did a lot of programming. This
included porting over my Ultima-style game system (called Explore),
but that never got good enough to release. Other new projects included
a library for reading and writing IFF (Interchange File Format)
multimedia files before Commodore released their own, a shared library
and driver for a good 68K disassembler, and a port of the old Peter
Langston Empire game (a multi-player non-graphical economics/war/
diplomacy game). The latter was again released as shareware, and I
still have contribution letters for it, too. From now on, I think I'll
just give things away, so I don't have to feel guilty about not
answering shareware letters! One fellow (Hi Hakan!) wrote a graphical
front end for Amiga Empire, and several of my friends and co-workers
have fond memories of the hours we spent plotting the demise of the
others' nations. One of my Amiga projects in Draco was the Toy
language and compiler, which was done for a series of magazine
articles.

Of course I eventually started another programming language project.
This was to be a set of shared libraries which allowed callers to
define their own programming language, consisting of the base language
implemented by my libraries, with extensions they added themselves. I
got a good ways with this, having libraries for the lexical scanner,
symbol tables, parser and pretty-printer. It could only handle
languages that were in the general style of Draco, but that didn't
(and still doesn't) bother me. However, I was getting bogged down with
the details of conversions between sizes of integral values, so when
another interesting project came up, I was ready for a short break.

That project was the writing of a simple MUD (Multi-User Dungeon)
server. I had an interest in multi-user games from my Empire work, and
I had an interest in adventure-type games from my Six/Fant work. So, a
simple MUD sounded like an excellent diversion. This was just going to
be a rough project, so I chose to name it AmigaDUM. Later, I would
make a real version of it, using the language libraries when they were
ready. Any MUD system I wrote was of course going to have a Draco-like
language in it! AmigaDUM progressed nicely, borrowing some parsing
ideas from a previous RPG project called Quest, and programming
language techniques and code from the libraries project. Then,
however, I decided it would be fun to add some multimedia stuff to
it.

From then on, what became known as AmigaMUD took over my play
programming. It started in 1990, and lasted until around 2001, when I
realized that a single non-artist like myself couldn't possibly
produce something on par with the large commerical or public domain
systems. AmigaMUD grew a custom multimedia client, custom serial
protocol, a real "sample" world, internet capabilities, etc. The
server itself has now been translated to C and ported to Linux,
renamed as CGMud.

A friend wrote a custom Java client for the system, putting in some
generality that wasn't in the original. That lead to changes and
additions to the MUD world, of course. However, that client lacks the
built-in editor, programming language parser, sound capabilities, etc.
that the original Amiga one had. The system also now has two execution
models - the original parse-tree interpreter and a new byte-code
interpreter. For much more information on AmigaMUD, click here. For a
short sample of AmigaMUD internal programming language code, look
here.

As of October 2003, the server is still running on my system here, but
the only connection attempts to it are all failing, likely due to
people trying to use a telnet protocol with the port for the custom
protocol.

There is also a programming language in the ToyMUD server, which was
done in the middle of the AmigaMUD project. As usual, here is a short
sample of some ToyMUD programming language code. I also did about 2/3
of an ANSI C compiler at work, but that was just work, not fun! There
could be some language/compiler work that I've missed in this
rambling, but I can't think of them...

Update - 2005-04-24 - for the last couple of years I've been slowly
working on yet another huge project. I somewhat jokingly call this one
my project to "replace all the world's software". Riiight! I still
don't even have a good name for it, but I've had considerable success
with some of the concepts in it. It's too soon for an interesting
sample, even though I do have a few thousand lines of code in it that
will run.


EOF
.

Relevant Pages

  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)
  • Re: A note on computing thugs and coding bums
    ... It would handle international characters if the execution character ... method I used in "Build Your Own .Net Language and Compiler". ... work areas and counting on Nul is an illusion. ...
    (comp.programming)
  • Re: WaitForSingleObject() will not deadlock
    ... represent an incorrect implementation of the language. ... the *compiler* does not guarantee this. ... but to state it in terms of the execution instead of the formal semantics of the language ... as long as the optimizations do not change the semantics of the language). ...
    (microsoft.public.vc.mfc)
  • Re: subroutine stack and C machine model
    ... Use a compiler optimizer ... higher determinism means that optimizer has more information. ... C programmers like to brag that their "language" is more ... prospective computer science majors at Princeton. ...
    (comp.lang.c)
  • Re: "STL from the Ground Up"
    ... are not features of a language. ... To support reflection you make a compiler embbed type and functional information in the compiled program. ... When the OCaml compiler is given a complicated nested pattern match it ... virtual const Base *clone= 0; ...
    (comp.programming)