Path: utzoo!utgpu!watmath!att!ucbvax!STONY-BROOK.SCRC.SYMBOLICS.COM!jrd From: jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) Newsgroups: comp.sys.atari.8bit Subject: cc65 Message-ID: <19891116170516.5.JRD@MOA.SCRC.Symbolics.COM> Date: 16 Nov 89 17:05:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 127 Date: Mon, 13 Nov 89 22:46 PDT From: > So has anybody been using CC65? Does it work? Yes, and yes. Great! Here are some execution times for the sieve of Eratosthenes running on a few of the languages available for the 8-bit Atari, including CC65: Language Jiffies Time ----------- ------- -------- Atari BASIC 186,752 51:52:32 Turbo BAS-I 72,554 20:09:14 CC8 / Ace-C 32,537 9:02:17 Turbo BAS-C 19,323 5:22:03 CC65 15,689 4:21:29 Kyan Pascal 9,418 2:36:58 That's pretty good. I never got around to doing benchmarks like that. [...] Some points of interest: 1) Compiling to machine language pays off; cc65 code is about twice as fast as cc8. Right. In fact, if you look at the generated code, it's pretty bad. It ought to be possible to get another factor of two or so by teaching the compiler to have a little more knowledge about expression context. 2) Kyan Pascal also compiles to machine language, but its code is still about twice as fast as cc65. Kyan Pascal is probably tuned for the Atari/6502. CC65 is essentially Small-C, so it uses generic operations for a lot of things that could be done slicker. [...] BYTE Magazine's "new" benchmarks (June 1988) are writted in Small-C and should be interesting for comparison to other machines (yah, I know, but it would be nice to know that fraction.) Yes. If you've got them in machine-readable form, please post them, I'll stick them in with CC65. Cc65 has some very good points: 1) A lot library calls that all have their proper UNIX-C names (Cc65 has many more than cc8, and cc8 had a few misnamed) More the the point, all the source and tools are available, so if there are ones I didn't put in that you want, they're trivial to add. If I got some wrong, they're trivial to fix. 2) "main(argc, argv) int argc; char **argv;" works beautifully 3) Respectable speed but needs some things to reach metaphysical execellence: 1) Real "float"s or, at least, a floating-point library I've thought about adding floats, but decided to post what I had first. In principle, they're not hard to add, but would bloat the compiler some, and space is pretty tight there already. 2) scanf(), sscanf() That should be easy to write. 3) "typedef"s 4) 32-bit longs (they don't need to be fast, just available) Same thing as applies to floats. In principle, it's not too terrible, but it's hard to know how to do it without taking too much space. I've found that I don't usually need stuff like that on the Atari, and when I do, it's usually something I can just whack up in assembly language. It would be nice to have the compiler know about it though. 5) getchar(), putchar(), Those are trivial to write. ungetc() ... and that's not to terrible; it would require fopen returning a structure instead of the IOCB. Shouldn't be a big deal. 6) A Graphics/Sound/Etc... library I was able to get many of the sample programs (like pmdemo.c) that came with CC8 to work, though some required a bit of hacking, as they were assuming all kinds of things about the CC8 runtime environment. If anyone comes up with anything useful, please post it. 7) A "-Iinclude.dir" option to take "#include <..>" files from a different directory than the default Ok, I'll see about adding that. 8) How about a malloc(), realloc(), and free() that use a few Rambo-XL banks for storage? (my ram disk could lose 16k or 32k [B[B without causing too much grief.) The problem here is accessing the variables in the program... That'd be nice, but I think it'd be hard. How would you be able to tell the difference between pointers that lived in directly addressabel memory and pointers that had to have base registers frobbed when you dereference them? Link65.com seems to fight the SpartaDOS X Time/Date line; I turn it off inside a batch file. Humph. I believe it works for me. What sort of lossage do you see? I use two batch files, c1.bat: x cc65 %1 and c2.bat: td off x ra65 %1.asm x link65 -o %1.com @%1.lnk td on because if there are any compilation errors, SDX will run along to the next stage and you have to wait 3 minutes to get back to your code. Question: could SDX be made to detect any errors and abort a batch file? I don't know, but if anyone does, could they post the answer? I'll build it into exit().