Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pacbell!att!alberta!filip From: filip@alberta.UUCP (Don Filipchuk) Newsgroups: comp.sys.amiga Subject: Re: Draco keywords : Update Keywords: Draco, update, PD compiler Message-ID: <251@cadomin.UUCP> Date: 16 Jun 88 19:58:07 GMT Reply-To: filip@cadomin.UUCP (Don Filipchuk) Organization: U. of Alberta, Edmonton, Alberta, Canada Lines: 71 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 ... Don