AMONSON@IDCSVAX.BITNET (11/14/89)
> 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!jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (11/17/89)
Date: Mon, 13 Nov 89 22:46 PDT
From: <AMONSON%IDCSVAX.BITNET@CUNYVM.CUNY.EDU>
> 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().ncastellano@eagle.wesleyan.edu (11/20/89)
In article <19891116170516.5.JRD@MOA.SCRC.Symbolics.COM>, jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes: > > Date: Mon, 13 Nov 89 22:46 PDT > From: <AMONSON%IDCSVAX.BITNET@CUNYVM.CUNY.EDU> > > > 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: > > [...etc...] Wow...I didn't know there was a C compiler for the 8-bit. Is it PD /shareware? where can i get it? nick -- _=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_- i believe in coyotes in time as an abstract explain the change the difference between what you want and what you need there's the key your adventure for today _-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_R.-E._M.=_-_= Nicholas Steven Castellano (dd) | entropy@nuacc.acns.nwu.edu | Disclaimer: I am ncastellano@eagle.wesleyan.edu | ncastellano@wesleyan.bitnet | irresponsible. _=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-
Chris_F_Chiesa@cup.portal.com (11/23/89)
> > So has anybody been using CC65? Does it work? > > Yes, and yes. Here are some execution times for the sieve of > Eratosthenes [etc...] Good Lord! Do I read this correctly? John Dunning has RELEASED CC65?? WHEN? I *thought* I was supposed to receive notice, John! :-) Shoot. This is what I get for using Portal, "where News reading is Hell!"... Must have missed the announcement AND the software, eh? If you couldn't tell, I WANT CC65!!!!! Please, somebody, anybody, e-mail me info on how to get it -- John Dunning, if you're reading this, especially! :-) Chris Chiesa Chris_F_Chiesa@cup.portal.com, formerly cfchiesa@bsu-cs.bsu.edu
rrwood@contact.uucp (roy wood) (11/16/90)
Has anyone had problems with running out of memory when using CC65? A friend of mine tried to compile a medium sized program and ran out of memory. Assuming he didn't do anything too stupid (he's reasonably technically knowledgeable), what MIGHT be the problem and solution? -Roy Wood
gdtltr@chopin.udel.edu (Gary D Duzan) (11/17/90)
In article <1990Nov16.151331.19920@contact.uucp> rrwood@contact.uucp (roy wood) writes: => =>Has anyone had problems with running out of memory when using CC65? A friend =>of mine tried to compile a medium sized program and ran out of memory. =>Assuming he didn't do anything too stupid (he's reasonably technically =>knowledgeable), what MIGHT be the problem and solution? => =>-Roy Wood A 64K machine? If it is important you can try the Unix cross-compiler version which supports significantly more compiler memory. Gary Duzan Time Lord Third Regeneration -- gdtltr@brahms.udel.edu _o_ ---------------------- _o_ [|o o|] An isolated computer is a terribly lonely thing. [|o o|] |_O_| "Don't listen to me; I never do." -- Doctor Who |_O_|
tribe@groucho (Mr Duane Tribe Esq) (11/17/90)
In article <1990Nov16.151331.19920@contact.uucp> rrwood@contact.uucp (roy wood) writes: > >Has anyone had problems with running out of memory when using CC65? ... > ... what MIGHT be the problem and solution? > >-Roy Wood It MIGHT be that one of the internal tables overran :-) :-) The compiler's table of characters from string constants is particularly tiny, like 256 bytes. The solution may be to break the program into smaller .C files and link up the .OBJ's with LINK65. -- Duane Tribe tribe@ted.cs.uidaho.edu
mwoodwar@eecs.wsu.edu (woodward matthew d - CS350) (01/22/91)
Lately, I have been trying to get CC65 and it's related stuff for my old 800. I ftp'd (binary mode) to an ATT 386 unix workstation, and used it's simul-task system with the util utility (writes an atari DD disk from an IBM compatible system), and brought it home happily (I used the /b(inary)) switch on util... None of the execs I have gotten will run, is there some translation going on somewhere that I have missed, or are other people finding that the com files don't work. I tried it with dos xl 2.35I, mydos 4.2c, and atari dos 2.5, and none of them work. Just wondering if anyone has had similar problems. I unarced cc65 arc on an IBM, but supunarc.com, which I got via the same path did not work either. Hmmmmm....Anyone have a suggestion? Matt Woodward
apc@cellar.UUCP (Lionel Ginzburg) (01/23/91)
mwoodwar@eecs.wsu.edu (woodward matthew d - CS350) writes: > Lately, I have been trying to get CC65 and it's related stuff for my > old 800. I ftp'd (binary mode) to an ATT 386 unix workstation, and used > it's simul-task system with the util utility (writes an atari DD disk from > an IBM compatible system), and brought it home happily (I used the /b(inary)) > switch on util... None of the execs I have gotten will run, is there some > translation going on somewhere that I have missed, or are other people findin > that the com files don't work. I tried it with dos xl 2.35I, mydos 4.2c, and > atari dos 2.5, and none of them work. Just wondering if anyone has had simil > problems. I unarced cc65 arc on an IBM, but supunarc.com, which I got via > the same path did not work either. Hmmmmm....Anyone have a suggestion? > Yeah, that Util file doesn't write binary files that well. I've looked at the source code, but not knowing C that well, couldn't see the problem. Your best bet would be to write the ARC file to the Atari DD disk-- if something's wrong with the file, you'll get a CRC error from the DeArcer on the 8-bit, but in my experience, ARC files transfer over pretty well. It occurs to me, in fact, that my own copy of supunarc.com was transferred from my AT clone to my 130XE via modem-- the fault, after all, is with util. So, if you have access to a modem for your 8-bit, that might be the best way of getting supunarc.com over. (Or, you could transfer everything over via modem or null modem, but that would defeat the purpose of util, wouldn't it :)) Stick to util for text or stuff that the non-Atari can recognize, like ARC. ------------------------------------------------------------------------------ EMail to: uunet!cellar!apc ------------------------------------------------------------------------------