Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!IDCSVAX.BITNET!AMONSON
From: AMONSON@IDCSVAX.BITNET
Newsgroups: comp.sys.atari.8bit
Subject: cc65
Message-ID: <8911160801.AA25485@ucbvax.Berkeley.EDU>
Date: 14 Nov 89 05:46:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 81

> So has anybody been using CC65?  Does it work?

Yes, and yes.  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

Each run calculated 10 iterations, finding primes to 8190.  Not tried
are pure machine language (I don't have the time) and Action! (I don't
have the cartridge.)  Some points of interest:

     1) Compiling to machine language pays off; cc65 code is about
twice as fast as cc8.
     2) Kyan Pascal also compiles to machine language, but its code is
still about twice as fast as cc65.

The code for the BASICs is obviously not identical to the code for
the Cs, and due to other conciderations this is only a rough idea of
relative speed.  I have found a few bugs in my version of the Turbo
BASIC Compiler:  Some complex expressions evaluate to wrong results,
and certain commands just won't compile.  This makes Turbo BASIC useful
for only simple programs that don't need to be compiled.  While Kyan
Pascal has a nice UNIX-like command line environment, it is nicer to
have access from the SpartaDOS X environment, and I just plain prefer
to code in C.  With Cc65's in-line assembly for hot-spots, it seems
a perfect development tool.

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.)

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)
     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
     2) scanf(), sscanf()
     3) "typedef"s
     4) 32-bit longs (they don't need to be fast, just available)
     5) getchar(), putchar(), ungetc()
     6) A Graphics/Sound/Etc... library
     7) A "-Iinclude.dir" option to take "#include <..>" files from a
        different directory than the default
     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...

Link65.com seems to fight the SpartaDOS X Time/Date line; I turn it
off inside a batch file.  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?

Has anyone seen the "lightspeed" C for the Atari?  I think it is not
even as good as cc8, if I remember the review in Antic correctly.  How
could someone sell such a thing?


Duane Tribe, University of Idaho (Ohio? no, Idaho)
Internet: tribe@ed.cs.uidaho.edu (129.101.100.25)

"If only you could see what I've seen with your eyes." -Roy Batty, Nexus 6.
Acnowledgements: Thanks, Paul, for posting this note!