filip@alberta.UUCP (Don Filipchuk) (06/17/88)
Here is a discussion I had with Chris Gray, author of Draco.
Sorry I didn't post it sooner...
--------------------------------------------------------------------
Subject: Draco and Amiga Programming
Date: Mon, 13 Jun 88 09:43:45 MDT
*> Hi Chris,
*> I read some articles about Draco in issue 2 of Amiga Transactor and
*> also the one recently published in Amazing Computing.
*> [ ramblings deleted ]
*> ...I don't know if I should pick up the earlier version of Draco on the
*> Fish disks or wait for the new version (eg. are there external differences
*> between the versions, or is it just in the guts of the compiler?).
The new version of the Draco compiler should be out in a couple of months.
One of the things I want to do is to add floating point support using the
new IEEE double precision library announced for AmigaDOS V1.3 . I don't have
that yet, so haven't started on that aspect. I'm currently working on adding
optimizations, i.e. improving the quality of the generated code. The old
version of the compiler works quite well, and anything written using it should
work without change on the new one.
*> Also, I had some questions about the compiler:
*> 1. Does the fact that it is a single-pass compiler preclude
*> #define type (pre-prosessor) statements like in 'C' ?
*> (Does a pre-processor add a lot of overhead and additional
*> time to the compilation process?)
Draco doesn't have a preprocessor, but many of the things that the C pre-
processor is used for are supported in Draco in different ways. E.g. it has
named constants (usually considered better than simple #define's), and has
conditional compilation using the existing 'if' construct. It does not have
any form of in-line procedure (which would replace parameterized macros).
Based on my work here at Myrias on an ANSI-C compiler, I can say that yes,
a preprocessor does add considerably to compile-time for C programs.
*> 2. Are the include files compressed (like Lattice) or pre-compiled
*> (like Manx) or neither (eg. would pre-compiled header files
*> require a special linker)? I recall reading about your
*> Draco-specific linked you were planning on porting. Is this
*> to be part of your "new release" ?
The old include files are not compressed, but do have all of the comments
stripped out, so are considerably smaller than the unstripped C ones. The new
include files are mildly compressed, using a single byte with the high order
bit set to replace various lengths of whitespace. I'm not currently planning
to port my linker - some changes to the way the current compiler generates
object files greatly reduces final object size. The current version of the
standard "Sieve of Eratosthenes" benchmark is a 5K object file, compared to a
7K file produced by Lattice C V4.0 (runs faster too!).
*> 3. You mentioned (in the Transactor article) that you had spent some
*> time developing a graphical game/adventure on the Amiga. Have you
*> worked on this at all or is this on the 'back burner', so to speak?
My graphics D & D game system (called Explore), along with a scenario (called
Amelon) has been running on my Amiga for a year or so. I haven't released it
because I want to improve the graphics in order to do justice to the Amiga.
That is currently awaiting the completion of the compiler upgrade.
*> Thanks for your time,
*> Don Filipchuk
---------------------------------------------------------------------------
So there you go, just an update on the current state of Draco.
Hope it wasn't too boring ...
Dondoug_rands_merritt@cup.portal.com (06/18/88)
Chris Gray is quoted (by Don Filipchuk) as saying: >Based on my work here at Myrias on an ANSI-C compiler, I can say that yes, >a preprocessor does add considerably to compile-time for C programs. Depends. The *standard* C preprocessor used with cc on Unix systems since the 70's does *not* "add considerably" to compile time. I timed it (the standard preprocessor) on a Unix system a few years ago. On large, *typical* programs (production code, and I tried a lot of different examples) it hit almost 50,000 lines per minute! By way of comparison, the C compiler itself averaged around 10,000 lines per minute. A very high level language compiler I wrote (which produced C as output) averaged 5,000 lines per minute on programs with simple constructs, and 2,500 lines per minute on typical programs with more complex constructs. This was on an Intel 310, which is a minicomputer-style machine based on the (ugh) 80286 with Vmebus interface. For various reasons I wrote a work-alike of the C preprocessor, and it averaged around 7,000 lines per minute in the same environment. Many preprocessors are equally slow. The reason that the *standard* C preprocessor (which is not, of course, used by Manx nor Lattice) is so blindingly fast, is that it uses just about every trick in the book. It is very difficult to make programs run at some kind of ultimate speed like this, but my hat is off to the author; you can't get much faster than that. It was only about 20% slower than "cp" (copy), which uses block buffering! So anyway, it all depends on which preprocessor you're talking about. Doug -- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug