K&R C?
Harry Potter
-----------
Joseph Rose, a.k.a. Harry Potter
Working magic in the computer community...or at least trying to! :(
Dombo
> What's the difference between K&R C and ANSI/ISO C?
http://en.lmgtfy.com/?q=What%27s+the+difference+between+K%26R+C+and+ANSI%2FISO+C
Lars Haugseth
rotflmao.
--
Lars Haugseth
Harry Potter
> Harry Potter schreef:
>
> > What's the difference between K&R C and ANSI/ISO C?
>
What about the library? Which ANSI C functions are unavailable, and
which are different? BTW, I want to use cc64 and Power C and,
perhaps, Turbo C.
lyricalnanoha
On Tue, 21 Jul 2009, Harry Potter wrote:
CC65 and Turbo C are both ANSI, at any rate, although Turbo C can handle
K&R.
I haven't had a need to use K&R for anything.
-uso.
Martijn van Buul
> I haven't had a need to use K&R for anything.
In fact, I would try to avoid using K&R at all cost.
--
Martijn van Buul - pi...@dohd.org
Lars Haugseth
>
> * lyricalnanoha:
>> I haven't had a need to use K&R for anything.
>
> In fact, I would try to avoid using K&R at all cost.
The second edition of Kernighan & Ritchie's "The C Programming Language"
has been updated to use ANSI C. That in itself should be a pretty strong
indication that K&R C is best left behind.
--
Lars Haugseth
Harry Potter
<lyricalnan...@usotsuki.hoshinet.org> wrote:
> CC65 and Turbo C are both ANSI, at any rate, although Turbo C can handle
> K&R.
>
that uses $i instead of #include and is made by one with little
knowledge of English, in case we're talking about two different Turbo
C's.
> I haven't had a need to use K&R for anything.
>
Will ANSI C work hosted on a C64/128? I plan to create one.
commodorejohn
which usually means it's for the Small-C subset of the C language
(http://en.wikipedia.org/wiki/Small_C) This is *not* ANSI, as it's
missing various features (i.e. floating-point.)
> Will ANSI C work hosted on a C64/128? I plan to create one.
Not sure what the question is here. Are you asking whether ANSI C can
be used on a Commodore? Obviously the answer is yes, as CC65 is ANSI.
Or are you talking about creating an ANSI C compiler that runs on a
Commodore?
Bill Buckels
Not me.
Aztec C for the C64 is a great cross-compiler as anyone who knows anything
at all about writing C programs in Windows that run on the C64 knows and it
is of course K&R.
Bill Buckels
"Lars Haugseth" <nj...@larshaugseth.com> wrote:
>That in itself should be a pretty strong indication that K&R C is best left
>behind.
Others might say that C itself is best left behind and we should write in
D.
What does the Commodore 64 indicate? K&R is vintage C just as the Commodore
64 is a vintage computer. The two work perfectly together.
I had great fun putting together the SID and Graphics routines for the Aztec
C64 cross-compiler. It works fine in Ubuntu under DOSEmu and in DOSBox as
well as in Windows Xp or Vista which is a pretty strong indication that it
is still useful on a variety of hosts albeit best used by those who
appreciate vintage tools and not some undeserving newbie.
On that point I am inclined to agree.
http://www.clipshop.ca/Aztec/compilers.htm#commodore
Other features of this K&R compiler are the use of overlays which is
something else that I like about the Aztec C64 compiler.
sampsa
> * Dombo <do...@disposable.invalid> wrote:
>
> > Harry Potter schreef:
> >> What's the difference between K&R C and ANSI/ISO C?
>
>
> rotflmao.
>
> --
> Lars Haugseth
This guy is such a tool. Joe/Harry, you are either one of the dumbest
posters or smartest trolls I've ever seen - which is it?
commodorejohn
> Others might say that C itself is best left behind and we should write in
> D.
>
> What does the Commodore 64 indicate? K&R is vintage C just as the Commodore
> 64 is a vintage computer. The two work perfectly together.
works best for you. Still, there are some fair criticisms of K&R C,
and it's missing some ANSI C features (void functions, struct
assignment, etc.) that really can make programming easier and less
error-prone.
Joel Koltner
news:08df1290-537b-4aa9...@32g2000yqj.googlegroups.com...
> Still, there are some fair criticisms of K&R C,
> and it's missing some ANSI C features (void functions, struct
> assignment, etc.) that really can make programming easier and less
> error-prone.
20 years from now you'll be able to say the same thing about languages we're
using today. :-)
The field of "computer science" didn't really exist when Kernigan and Ritchie
were crafting the original C spec...
Bill Buckels
And also some fair criticisms of the Commodore 64 but not by me.
>and it's missing some ANSI C features (void functions, struct assignment,
>etc.) that really can make programming easier and less error-prone.
The Commodore 64 is missing features such as ROM and an Operating System
that really can make programming easier as well. The Apple //e has both
these, but certain people like me don't need or want all that new-fangled
complexity all the time.
My programming is hardly error prone either whether I use K&R or ANSI or ISO
C or whether I program for the C64,
http://www.c64classics.ca
http://www.c64classics.ca/index.htm#gdemo
http://www.c64classics.ca/index.htm#sdemo
Apple //e, or
IBM-PC or
http://www.clipshop.ca/
http://www.teacherschoice.ca/
CP/M 80, Mac, Linux or whatever.
Others will shoot themselves in the foot even in Ladybug Logo or BASIC or
whatever and others won't.
Trolls who do nothing won't but we can always hope.
All I can say in addition to all this is that Aztec C Rules!, K&R or not...
http://www.aztecmuseum.ca/compilers.htm#commodore
Brandon Staggs
Regardless of the standard, K&R's "The C Programming Language" is
probably the best (technical) programming book I've read. I have the
updated edition that has the ANSI stuff.
And I don't even program in C unless I really have to.
--
-Brandon
http://www.brandonstaggs.com/c64.html
commodorejohn
wrote:
> The field of "computer science" didn't really exist when Kernigan and Ritchie
> were crafting the original C spec...
advancements at once. The changes from K&R to ANSI C were born out of
years of trial and error by many different users of the language, and
it would be silly to degrade something for not being its own
successor. K&R C is still a good language, and light-years better than
some other languages available on the Commodore (precisely WHY did
they do a COBOL implementation, again?) I'm just saying that, other
concerns aside (which is a fairly large caveat, considering how
library availability and customization to the target machine can
factor into the equation, and of course the all-important personal
preference,) ANSI C is generally a better language. All due respect to
K&R C for being there first, but ANSI C is still better *when
evaluating it solely as a language.*
lyricalnanoha
> The Commodore 64 is missing features such as ROM and an Operating System
> that really can make programming easier as well. The Apple //e has both
> these, but certain people like me don't need or want all that new-fangled
> complexity all the time.
Yeah, sometimes when trying to port stuff the lack of commands like
CLS/HOME, VTAB/HTAB/LOCATE, or even graphics functionality just has me
headwalling :/
I've even thought about whether porting FPBASIC itself to the 64 might be
of use for some stuff I want to do, n/m that C64 BASIC is almost FPBASIC
already.
-uso.
Martijn van Buul
>
> "Martijn van Buul" <pi...@dohd.org> wrote:
>>In fact, I would try to avoid using K&R at all cost.
>
> Not me.
>
> Aztec C for the C64 is a great cross-compiler as anyone who knows anything
> at all about writing C programs in Windows that run on the C64 knows and it
> is of course K&R.
CC65 is a great cross compiler, can be legally had, is open source, and has
been developed by a number of people who used to frequent this very newsgroup..
And, it is of course ANSI :)
Groepaz
> CC65 and Turbo C are both ANSI, at any rate, although Turbo C can handle
> K&R.
cc65 can handle k&r too (afaik that is a requirement for an ansi-c compiler)
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
Eine Diskussion ist unmï¿œglich mit jemandem, der vorgibt, die Wahrheit nicht
zu suchen, sondern schon zu besitzen.
<Romain Rolland>
Groepaz
indeed. aztec-c is pretty poo compared to it =P
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
It doesn't matter who votes. What matters is who counts the votes.
<Josef Stalin>
Groepaz
> On Jul 21, 9:45ï¿œam, lyricalnanoha
> <lyricalnan...@usotsuki.hoshinet.org> wrote:
>> CC65 and Turbo C are both ANSI, at any rate, although Turbo C can handle
>> K&R.
>>
> I said cc64, NOT cc65.
link to it please
> As for Turbo C, I am talking about the one
> that uses $i instead of #include and is made by one with little
> knowledge of English, in case we're talking about two different Turbo
> C's.
link to it please
>> I haven't had a need to use K&R for anything.
>>
> Will ANSI C work hosted on a C64/128? I plan to create one.
link to it please
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
Aesthetic delight lies somewhere between boredom and confusion.
<E.H.Gombrick>
Groepaz
> On Jul 22, 11:37 am, Harry Potter <maspethro...@aol.com> wrote:
>> I said cc64, NOT cc65.
> Looking at CC64's documentation, it says it's "a small C compiler,"
> which usually means it's for the Small-C subset of the C language
> (http://en.wikipedia.org/wiki/Small_C) This is *not* ANSI, as it's
> missing various features (i.e. floating-point.)
cc65 is a small-c based compiler too :) (and it also doesnt have floating
point - which you dont need anyway and should avoid at any cost on a
8bit/1mhz machine)
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
Ich ziehe meinen Hut vor den Hackern. Die zeigen denen, die fï¿œr ihre
angeblich todsicheren Codes Millionen und Milliarden investiert haben, dass
sie fï¿œr das Knacken von Codes nur eine halbe Stunde gebraucht haben.
<Rod Gonzalez>
Spiro Trikaliotis
Groepaz wrote:
> cc65 can handle k&r too (afaik that is a requirement for an ansi-c compiler)
No, it is optional only for a C89/C90 compiler.
Regards,
Spiro.
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
Bill Buckels
"Groepaz" <gro...@gmx.net> wrote:
>cc65 is a small-c based compiler too :) (and it also doesnt have floating
>point - which you dont need anyway and should avoid at any cost on a
>8bit/1mhz machine)
Aztec C is a better compiler since smarter people wrote it, it is legally
available by permission of its copyright holder, uses overlays, is K&R and
has floating point which in fact is very handy for writing programs like the
following and works fine on 8bit machines which is what made Aztec the
largest selling 8 bit C compiler in the 1980's .
http://www.aztecmuseum.ca/compilers.htm#commodore
http://www.aztecmuseum.ca/time64.zip
CC65 is poo by comparison regardless of who frequented this ng at one time.
What have they done lately? Until they do what I have done in Aztec C and
other C's I doubt if their opinions can be taken seriously.
Bill Buckels
"lyricalnanoha" <lyrica...@usotsuki.hoshinet.org> wrote:
>I haven't had a need to use K&R for anything.
That's because you haven't tried any of my Aztec C distributions yet uso...
if you did then you might have a need to use K&R and Aztec C for
everything:)
Aztec C Apple II DOS 3.3 and ProDOS 8, C64, and CP/M 80 compilers might be
worth a try...
lyricalnanoha
In the 6502 realm CC65/CA65 has served my purposes fine. In the Z80
realm, Hitech had an ANSI compiler which is still out and about (and I
think it's still commonly used in MSX circles).
I honestly don't see what advantage Aztec could have other than in library
support, and even that isn't impossible to replicate.
-uso.
commodorejohn
<lyricalnan...@usotsuki.hoshinet.org> wrote:
> In the 6502 realm CC65/CA65 has served my purposes fine. In the Z80
> realm, Hitech had an ANSI compiler which is still out and about (and I
> think it's still commonly used in MSX circles).
low-end systems (although MSX and CP/M support are rather limited
right now.)
> I honestly don't see what advantage Aztec could have other than in library
> support, and even that isn't impossible to replicate.
Eh, if Aztec C has a better code generator than CC65, that could make
a real difference on such low-end hardware. However, I don't really
know if that's the case, and even so, some programmers (myself
included) might feel that the features added in ANSI C make up for any
slight deficiencies in other areas.
Honestly, Mr. Buckels seems to just be offended that people might
prefer another product to his compiler of choice, which, in the
absence of hard comparisons to back it up, is pretty silly.
Groepaz
really: LOL
you know, there is a reason for you beeing the only aztec-c user. and there
is a reason for the only time anyone ever hears about this compiler, it's
your constant ramblings about it here.
also: LOL
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
Der Zyniker sieht die Welt wie sie ist, nicht wie sie sein sollte.
Groepaz
> Hello Gpz,
>
> Groepaz wrote:
>
>> cc65 can handle k&r too (afaik that is a requirement for an ansi-c
>> compiler)
>
> No, it is optional only for a C89/C90 compiler.
ok =) i don't think i have ever stumbled about a compiler that does ansi-c
and NOT k&r :) or mmmh.... maybe sdcc? dont recall =)
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
...nuclear war could alleviate some of the factors leading to today's
ecological disturbances that are due to current high population
concentrations and heavy industrial production.
<US Office of Civil Defense>
Groepaz
> Eh, if Aztec C has a better code generator than CC65, that could make
> a real difference on such low-end hardware. However, I don't really
> know if that's the case,
the differences are, lets say.... not worth talking about. infact when i
tested a few compilers some years ago, "power-c" produced the
most "optimal" (from an assembler programmer point of view) code - but at
the same time power-c is kinda limited in features (k&r, preprocessor is
crap etc). aztec-c and cc65 produce similar code quality, with cc65 beeing
MUCH more bugfree, especially in border situations. cc65 is also the only
available 6502 compiler that even vaguely follows some standards.
if you want some hints on how bad a certain compiler fails, you can try
http://hitmen.c02.at/files/cc65/testsuite_test3.tar.gz (many tests are also
available in k&r even)
[some day i should finally clean up and commit my floating point library so
those who think they really need them can stop whining too =P]
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
It is not possible to simultaneously understand and appreciate the Intel
architecture.
<Ben Scott>
Bill Buckels
"commodorejohn" <commod...@gmail.com> wrote:
>lyricalnanoha wrote:
>> library support
That's one area and overlay and floating point support are two other areas.
Inline assembly is a third area. But you are right. It is worth downloading
my Aztec C distributions just to play with the samples and library source.
>>that isn't impossible to replicate
Why reinvent the wheel?
http://aztecmuseum.ca/ads/nibble-jul-84-aztec.pdf
>Mr. Buckels seems to just be offended that people might prefer another
>product to his compiler of choice
No because these people don't really prefer anything. Most just don't know
my Aztec C distributions because they've never tried them and therefore
don't know anything. Yet.
And I am not really offended. What I think is silly is to preclude trying a
good compiler because it is old and not ANSI. ANSI support is a very silly
reason to condemn a compiler or rather to solely use to chose one compiler
over another. Very very silly. Tsk tsk tsk.
http://aztecmuseum.ca/ads/index.htm
>which, in the absence of hard comparisons to back it up, is pretty silly.
The comparisons for Aztec C are a matter of history and it was always really
good but some of these others like the people who use them haven't the same
history but performance is not the only criteria. If it is important here's
a link:
http://www.textfiles.com/programming/dstone.c
But especially try this link:
http://en.lmgtfy.com/?q=drhystone+compiler+Aztec+C+apple+performance
What is also pretty silly is that a bunch of people who haven't used Aztec C
share a silly opinion on it. These are people who may not have ever used an
overlay or done some of the other silly fun stuff that doesn't care whether
a compiler is ANSI or not:
http://www.aztecmuseum.ca/projects.htm#dos33
http://www.aztecmuseum.ca/projects.htm#prodos
http://www.aztecmuseum.ca/projects.htm#c64
So forgive me for being silly and I'll forgive you back.
One thing for sure... if nobody is going to use the Aztec C distributions
that I have put together, nobody is surely going to use anything that Joseph
Rose puts together.
- The Aztec C Evangelist:)
Bill Buckels
"Groepaz" <gro...@gmx.net> wrote:
>you know, there is a reason for you beeing the only aztec-c user.
There were actually more than one Aztec C users. Aztec C outsold all other C
compilers in the mid-1980's but newbies like you can be forgiven for not
knowing your history.
http://en.wikipedia.org/wiki/Aztec_C
The reason is that I was doing cross-development for the C64 on my IBM-PC
about 30 years ago and actually paid for a licence which cost more than
several Commodore 64's. At that time the average C64 user wasn't buying much
and also not so many did cross-development work on the IBM-PC and many could
not even afford an IBM-PC.
http://en.wikipedia.org/wiki/Cross-compiler#Manx_Aztec_C_cross_compilers
Plain and simple... it was so expensive and specialized that despite the
fact that it was good only serious professional cross-platform developers
used it.
Today with the C64 and other 6502 and Z80 development now being done on
cross-compilers the Aztec C cross-compiler is accesible to others who could
not have ever afforded it when I purchased it.
>and there is a reason for the only time anyone ever hears about this
>compiler, it's your constant ramblings about it here.
That might be true if the "anyone" that you are talking about is within this
ng or a hitman or something. Also LOL.
And that is also the reason your opinion is worthless on this compiler.
Groepaz
> There were actually more than one Aztec C users.
yes. *were*. what about now?
> Aztec C outsold all other
> C compilers in the mid-1980's but newbies like you can be forgiven for not
> knowing your history.
LOL again. back in the days i quickly went from basic compilers (yuck!),
over pascal compilers (slightly better), several c-compilers (acceptable
but still suboptimal) to plain assembler. simply because there is only very
limited use for compilers on 8bit targets for games and demos and alike.
(and ofcourse it is still like that)
> The reason is that I was doing cross-development for the C64 on my IBM-PC
> about 30 years ago and actually paid for a licence which cost more than
> several Commodore 64's. At that time the average C64 user wasn't buying
> much and also not so many did cross-development work on the IBM-PC and
> many could not even afford an IBM-PC.
you'd be surprised how common cross development was even back then. but
indeed, mostly it was about assembler, not compilers. does datels PDS tell
you anything?
> Plain and simple... it was so expensive and specialized that despite the
> fact that it was good only serious professional cross-platform developers
> used it.
bullshit, price means nothing. (and all compilers were crazy expensive,
except the most terrible ones) you can also always get the helluva
expensive "professional" 6502 and 65816 compiler from wdc - guess why
people still prefer cc65 though, even the sunplus guys =P
so did you ever compare the generated code to that of cc65? (i wish i would
have kept the output of the tests)
> That might be true if the "anyone" that you are talking about is within
> this ng or a hitman or something. Also LOL.
so you surely have some links to recent non trivial projects done with it?
something like for example zoomania
(http://noname.c64.org/csdb/release/?id=74653) or contiki
(http://www.sics.se/contiki/)
(links to actual binaries for a c64 please)
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
I am pretty sure that whenever you make the statement "I am right and the
entire industry is wrong." you are, in fact, the one who is wrong. Unless
your name happens to be Steve Wozniak, and it happens to be 1976.
Bill Buckels
"Groepaz" <gro...@gmx.net> wrote:
>aztec-c and cc65 produce similar code quality
I wonder why I should believe this statement because you also wrote:
>you know, there is a reason for you beeing the only aztec-c user. and there
>is a reason for the only time anyone ever hears about this compiler, it's
>your constant ramblings about it here.
I think the more constant of the ramblings may be the ramblings about CC65
and nothing much that wasn't already done a long time before. This whining
of bugs in Aztec C seems to be arguable based on my experience... my Aztec C
code for the C64 seems to work pretty well.
>[some day i should finally clean up and commit my floating point library so
>those who think they really need them can stop whining too =P]
Why reinvent the wheel? Aztec C does floating point and has for 30 years.
Of course I do agree that floating point should also be used optimally as in
the Aztec C code below which is used to draw the hands on a clock in one of
my Aztec C programs for the C64 and the Apple II:
(just use floats where required and use integers to store results - only a
fool would do otherwise on an 8bit machine:)
circlepoints(x,y,baselength,fdegrees)
int *x, *y;
int baselength;
float fdegrees;
{
float xtemp;
float ytemp;
int degrees = (int )fdegrees;
float aspect_h, aspect_v;
aspect_h = (float)1.16;
aspect_v = (float)1;
/* starting at 12 O'clock */
/* use a switch for the break */
switch(degrees)
{
default:
/* within range */
if(degrees<0 || degrees >359)degrees=0;
/* 0-45 sin */
if(degrees < 45)
{
xtemp = (float) sine_cosine[degrees][0];
ytemp = (float) sine_cosine[degrees][1];
ytemp = ytemp * -1;
break;
}
/* 45-90 cos */
if(degrees < 90)
{
xtemp = (float) sine_cosine[90-degrees][1];
ytemp = (float) sine_cosine[90-degrees][0];
ytemp = ytemp * -1;
break;
}
/* 90 - 135 */
if(degrees < 135)
{
xtemp = (float) sine_cosine[degrees-90][1];
ytemp = (float) sine_cosine[degrees-90][0];
break;
}
/* 135 - 180 */
if(degrees< 180)
{
xtemp = (float) sine_cosine[180-degrees][0];
ytemp = (float) sine_cosine[180-degrees][1];
break;
}
/* 180 - 225 */
if(degrees< 225)
{
xtemp = (float) sine_cosine[degrees-180][0];
xtemp = xtemp * -1;
ytemp = (float) sine_cosine[degrees-180][1];
break;
}
/* 225 - 270 */
if(degrees< 270)
{
xtemp = (float) sine_cosine[270-degrees][1];
xtemp = xtemp * -1;
ytemp = (float) sine_cosine[270-degrees][0];
break;
}
/* 270 - 315 */
if(degrees< 315)
{
xtemp = (float) sine_cosine[degrees-270][1];
xtemp = xtemp * -1;
ytemp = (float) sine_cosine[degrees-270][0];
ytemp = ytemp * -1;
break;
}
/* 315 - 360 */
xtemp = (float) sine_cosine[360-degrees][0];
xtemp = xtemp * -1;
ytemp = (float) sine_cosine[360-degrees][1];
ytemp = ytemp * -1;
}
ytemp = ytemp/32767;
xtemp = xtemp/32767;
xtemp *= (aspect_h*baselength);
ytemp *= (aspect_v*baselength);
*x += (int )xtemp;
*y += (int )ytemp;
}
Bill Buckels
"Groepaz" <gro...@gmx.net> wrote:
>I am pretty sure that whenever you make the statement "I am right and the
>entire industry is wrong." you are, in fact, the one who is wrong. Unless
>your name happens to be Steve Wozniak, and it happens to be 1976.
I agree.
Groepaz
yeah, and you dont have a serious comment on the rest, that shows.
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
Homes for the homeless, jobs for the jobless, neverthe for the nevertheless.
Groepaz
> "Groepaz" <gro...@gmx.net> wrote:
>
>>aztec-c and cc65 produce similar code quality
>
> I wonder why I should believe this statement because you also wrote:
how exactly is one related to the other?
>>you know, there is a reason for you beeing the only aztec-c user. and
>>there is a reason for the only time anyone ever hears about this compiler,
>>it's your constant ramblings about it here.
>
> I think the more constant of the ramblings may be the ramblings about CC65
> and nothing much that wasn't already done a long time before. This whining
> of bugs in Aztec C seems to be arguable based on my experience... my Aztec
> C code for the C64 seems to work pretty well.
and what will you do if it doesnt? as you said yourself, there are more
important aspects than code quality. and one *very* important aspect when
choosing a compiler is that if a bug is found (and no program is bugfree
ever, especially not compilers, so its likely to happen at some point) that
it can be fixed. bugs in cc65 usually get fixed quickly, and in the last
few years it became amazingly stable, well maintained, and mostly standard
compliant. aztec looses hands down in all of these aspects.
>>[some day i should finally clean up and commit my floating point library
>>[so
>>those who think they really need them can stop whining too =P]
>
> Why reinvent the wheel? Aztec C does floating point and has for 30 years.
and? floats on 8bit machines are mostly a gimmick anyway. there isnt much
that cant be done without them, and most of the time you dont want them at
all for speed reasons.
> Of course I do agree that floating point should also be used optimally as
> in the Aztec C code below which is used to draw the hands on a clock in
> one of my Aztec C programs for the C64 and the Apple II:
>
> (just use floats where required and use integers to store results - only a
> fool would do otherwise on an 8bit machine:)
you seriously consider THAT code optimal? you must be kidding. the same can
be achived *easily* without using floats at all - and the resulting code
will be both faster and smaller.
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
The world is a madhouse, so it's only right that it is patrolled by armed
idiots.
<Brendan Behan>
Bill Buckels
"Groepaz" <gro...@gmx.net> wrote:
>bullshit, price means nothing.
I can also agree with at least part of this statement:)
>so did you ever compare the generated code to that of cc65? (i wish i would
>have kept the output of the tests)
I was never much interested in CC65 and never even knew about it until long
after I resurrected my Aztec C cross-compilers and made them available
online for the Apple II and C64 with my libraries.
The one area that I feel is required for the C64 and Apple II is overlays. I
also like to create SYS programs in ProDOS 8 for my Apple //e and to provide
memory holes and so forth with my linker. Aztec C provides this and more.
So to say of CC65:
>aztec-c is pretty poo compared to it
is truly bullshit and on that I think we can both agree on.
Groepaz
>>so did you ever compare the generated code to that of cc65? (i wish i
>>would have kept the output of the tests)
>
> I was never much interested in CC65 and never even knew about it until
> long after I resurrected my Aztec C cross-compilers and made them
> available online for the Apple II and C64 with my libraries.
so, seeing that i actually DID look at aztec-c and power-c and turbo-c and a
few more and compared them to cc65.... wow. where are your pulling your
insights out of?
> The one area that I feel is required for the C64 and Apple II is overlays.
> I also like to create SYS programs in ProDOS 8 for my Apple //e and to
> provide memory holes and so forth with my linker. Aztec C provides this
> and more.
and? cc65 provides "overlay" functionality too. and even support for
loadable modules which are linked and relocated at runtime (think "dll").
really the only thing that cc65 can not do that a lot of other old 6502 can
is floating point support. which noone seriously misses really =)
> So to say of CC65:
>
>>aztec-c is pretty poo compared to it
>
> is truly bullshit and on that I think we can both agree on.
it seems that unlike you, i have actually looked at both. so how can you
make your claim? *shrug*
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
The Scene always wins.
Groepaz
> really the only thing that cc65 can not do that a lot of other old 6502
> can is floating point support. which noone seriously misses really =)
...old 6502 compilers... (ofcourse)
and to add on it: it's not that cc65 is incapable of floating point support,
its that noone bothered to write a proper standard compliant (! which most
if not all compilers for the c64 are NOT in that regard) lib for it. simply
noone cares because noone needs it.
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
Tradition is what you resort to when you don't have the time or the money to
do it right.
<Kurt Herbert Adler>
Bill Buckels
"Groepaz" <gro...@gmx.net> wrote:
>yeah, and you dont have a serious comment on the rest, that shows.
Watch those flames... I may need to dust-off my old arsenal:)
Of course I made a serious comment (see my other message). The only thing
that shows here is your impatience in waiting for a reply.
>back in the days i quickly went from basic compilers (yuck!), over pascal
>compilers (slightly better), several c-compilers (acceptable but still
>suboptimal) to plain assembler. simply because there is only very limited
>use for compilers on 8bit targets for games and demos and alike.(and of
>course it is still like that)
back in the day I went from basic compilers almost immediately into C
augmented with assembler for performance and always made a pretty good
living as a C programmer. In Windows 3.1 and in unix I dropped the assembler
for the most part and it stayed that way.
Our needs are different. But it seems that a self-avowed assembly language
programmer (you) should hold a little about whether a C compiler is better
when talking to a self-avowed C programmer (me).
Regardless, I still say that whether a C compiler is K&R or ANSI is not as
big a deal as what you can do with the compiler. That is my whole point in
pushing my old Aztec C compiler.
I'm pretty much done for now unless you keep it up.
Bill Buckels
"Groepaz" <gro...@gmx.net> wrote:
>so, seeing that i actually DID look at aztec-c and power-c and turbo-c and
>a few more and compared them to cc65.... wow. where are your pulling your
>insights out of?
I have since looked at cc65 briefly and I am not much interested in native
mode compilers. Your insights seem to be suited to you just as mine are
suited to me.
>and? cc65 provides "overlay" functionality too.
Not when I looked at it.
>and even support for loadable modules which are linked and relocated at
>runtime (think "dll").
This is easy enough to add to any compiler.
>it seems that unlike you, i have actually looked at both. so how can you
>make your claim? *shrug*
I thought you made the claim:) Oh well.
>The Scene always wins.
I get it now... you just want the last word:) Me Too.
http://www.appleoldies.ca/MeToo.pdf
Groepaz
> I have since looked at cc65 briefly and I am not much interested in native
> mode compilers.
hu? native mode compilers? are we talking about the same thing? how is cc65
a "native mode" compiler? last time i checked it was a full featured
crosscompiler toolchain. *shrug*
>>and even support for loadable modules which are linked and relocated at
>>runtime (think "dll").
>
> This is easy enough to add to any compiler.
"but why reinvent the wheel?"
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
When someone says 'I want a programming language in which I need only say
what I wish done,' give him a lollipop.
<Alan J. Perlis>
Groepaz
> Our needs are different. But it seems that a self-avowed assembly language
> programmer (you) should hold a little about whether a C compiler is better
> when talking to a self-avowed C programmer (me).
uh. i am making a living by programming C myself for urks, long now. and
doing this in the console/handheld/embedded area i have used quite a bunch
of different (and sometimes obscure) compilers of vastly varying quality,
and fought my way through the different quirks of all of those - so i dare
to say that i can very well comment on this kind of topic. and beeing a
sucker for handwritten assembler isnt the worst help with judging compiler
output either :)
to make a really unrelated and useless example, i might say that aztec-c
surely beats sdcc in terms of useability, and i would recommend aztec-c
over it (do they actually share some target? i dont know) - not because i
have compared them, but because i have used sdcc a fair bit and found that
it tries to be a c-compiler really hard, but is epic fail in some areas =)
> Regardless, I still say that whether a C compiler is K&R or ANSI is not as
> big a deal as what you can do with the compiler. That is my whole point in
> pushing my old Aztec C compiler.
i can agree on that. however the thing with k&r is, that thanks to the non
existing standard, you have to know a specific compiler very well to be
able to use it properly, and to not run into funny surprises. thats why
many, including me (as i guess is obvious =P), have a strong preference to
standard compliant ansi-c compilers - you can mostly use them without
knowing its specific quirks, as they will (hopefully =P) all behave the
same. in particular with 8bit targets there are enough things to consider
already when programming in C, so if it's possible to skip, or atleast
radically shorten, the "learn how this compiler works" part and you can do
it by simply using another tool, then there is little reason not to do it.
(and before you mention it again: the libraries supplied with a compiler are
a strong reason indeed. and thats infact another reason why i really like
cc65, it comes with a nice almost fully standard compliant library, which
simply behaves as expected. it admittedly lacks a bit in the generic
graphics and sound department - but then again this kind of stuff almost
always requires specific code for a specific application anyway, so it is
not a big loss, if at all)
and now, since i dont have any windows box handy right now, i'd like to see
a aztec-c compiled binary of
http://hitmen.c02.at/files/cc65/minicast_0.0.1.tar.gz (precompiled with an
older cc65 here: http://hitmen.c02.at/files/cc65/minicast.prg ). i'm
curious to see the difference now :)
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
If only God would give me a clear sign! Like making a large deposit in my
name at a Swiss bank.
<Woody Allen>
lyricalnanoha
On Sun, 26 Jul 2009, Bill Buckels wrote:
> And I am not really offended. What I think is silly is to preclude trying a
> good compiler because it is old and not ANSI. ANSI support is a very silly
> reason to condemn a compiler or rather to solely use to chose one compiler
> over another. Very very silly. Tsk tsk tsk.
Using K&R C when ANSI C is available is like using INTBASIC on the Apple
//e.
(For the benefit of non-Apple users here, INTBASIC is the 6K BASIC
interpreter from the original Apple ][. Faster, less buggy, yes...but
much more frustrating to work with because of its limitations and
oddnesses.)
-uso.
commodorejohn
> Why reinvent the wheel?
Because sometimes you have nicer tools and newer information and can
make a better wheel.
> One thing for sure... if nobody is going to use the Aztec C distributions
> that I have put together, nobody is surely going to use anything that Joseph
> Rose puts together.
Well, no argument *there.*
J. Robertson
>
>hu? native mode compilers?
Got me what he meant. I've been running the Windows version of the
CC65 compiler. I guess I could copy the Windows version to a disk and
try running it on a C64. ;-)
Wait! I got it. Maybe Ullrich has been working on a secret project of
a native C64 version and hasn't told us yet. I'll check the site at
*cough* www.cc65.org *cough*. Hmm, nope not there. He must not have
been looking at the right thing. Oh well.
Jason
Anssi Saari
> Spiro Trikaliotis wrote:
>
>> Hello Gpz,
>>
>> Groepaz wrote:
>>
>>> cc65 can handle k&r too (afaik that is a requirement for an ansi-c
>>> compiler)
>>
>> No, it is optional only for a C89/C90 compiler.
>
> ok =) i don't think i have ever stumbled about a compiler that does ansi-c
> and NOT k&r :) or mmmh.... maybe sdcc? dont recall =)
GCC manual (I have 4.3.2 here) has a chapter listing incompatibilities
with K&R. Since the -traditional option now affects only the
preprocessor, there's no way to turn on a K&R mode any more. So only
K&R stuff that's compatible with the standard chosen is supported. One
simple K&R example that doesn't work is:
typedef int foo;
typedef long foo bar;
Can't use a typedef in a typedef, so the latter needs to be
typedef long int bar;
Anyway, gcc does support the K&R style function declaration and
implicit ints, which are probably the most common thing.
Bill Buckels
"Groepaz" <gro...@gmx.net> wrote:
>Bill Buckels wrote:
> I have since looked at cc65 briefly
Of course cc65 is a cross-compiler. But I can see that you are confused by
my use of the conjunction "and" in my sentence. Just think bitwise...
English syntax can work that way.
>and I am not much interested in native mode compilers.
Like Power C.
How about I say "I have since looked at cc65 briefly. I have not looked at
native mode compilers for the C64 since I am not much not much interested in
native mode compilers although I have taken time to download Power C."
>hu? native mode compilers? are we talking about the same thing?
I was talking but you are having trouble listening. Therefore I am writing a
paragraph where a sentence should do.
>how is cc65 a "native mode" compiler? last time i checked it was a full
>featured
crosscompiler toolchain. *shrug*
You do go on and on and on about this foodchain of yours.
Bill Buckels
"J. Robertson" <jk...@juno.com> wrote:
>Wait! I got it. Maybe Ullrich has been working on a secret project of a
native C64 version and hasn't told us yet. I'll check the site at *cough*
www.cc65.org *cough*. Hmm, nope not there. He must not have been looking at
the right thing. Oh well.
Try http://www.foad.com Jason:) I think devnull can redirect your confusion.
Bill Buckels
"Groepaz" <gro...@gmx.net> wrote:
>and doing this in the console/handheld/embedded area
Yeah I have done lots of this too and device drivers and so forth. I have
lived many years in codeview and dbx both before getting fancy IDE's. My
most fluent assembler was 8086 in which I was conversational but when I talk
about C programming on these little boxes I am writing applications with
graphics and sound and stuff.
>and now, since i dont have any windows box handy right now, i'd like to see
>a aztec-c compiled binary.
Yeah ok. But you don't need a Windows box for Aztec C.
http://www.aztecmuseum.ca/docs/notes.htm
Using Aztec C in Linux
http://www.aztecmuseum.ca/docs/linux.txt
You can download several Aztec C compiled binaries from the website. I'll
compile the one that you sent under Aztec C and post the link when I am done
if it compiles without much change.
J. Robertson
wrote:
>Try http://www.foad.com Jason:) I think devnull can redirect your confusion.
Nice attempt at redirection and avoiding to give a proper response.
;-) You've done that a few times in this thread already. You can't
give straight answers to some things? That's ok, no one is perfect.
:-)
So, did you find the right CC65 compiler yet? Oh, I know what
happened, you didn't bother to read anything on the CC65 site and just
assumed that CC65 was native. :-)
Jason
J. Robertson
>So, did you find the right CC65 compiler yet?
I see further down in the thread you did answer. Amazing! :-)
Oh well!
Jason
Bill Buckels
"Groepaz" <gro...@gmx.net> wrote:
>and now, since i dont have any windows box handy right now, i'd like to see
>a aztec-c compiled binary of
>http://hitmen.c02.at/files/cc65/minicast_0.0.1.tar.gz
This code looks pretty specific to cc65.
Tell you what... you port the following project to cc65 and get it to
compile and run. I would like to see that.
http://www.aztecmuseum.ca/time64.zip
Bill Buckels
"J. Robertson" <jk...@juno.com> wrote:
>So, did you find the right CC65 compiler yet?
When I tried CC65 the snapshot was broken. Aztec C wasn't broken and I just
continued to use what worked for me. That was quite some time (a year or so)
ago and maybe CC65 would work for me now.
I was never under the misimpression that CC65 was a native mode compiler,
but when I wrote the cross-compiler article on Wikipedia I must confess that
I did not even mention CC65 but I certainly mentioned Aztec C. And Microsoft
C.
>I see further down in the thread you did answer. Amazing! :-)
What is it you are saying exactly Jason? Are you really another of these
CC65 munchkins of the great Oz's??? <g> or are you going to say something
besides making fun of me.
Remember that my initial position is that K&R is not bad if the compiler is
good and since Aztec C works well for me I don't see much advantage to ANSI.
Bill Buckels
"lyricalnanoha" <lyrica...@usotsuki.hoshinet.org> wrote:
>Using K&R C when ANSI C is available is like using INTBASIC on the Apple
//e.
bah!
How about saying "using K&R C when ANSI C is available is like using an
Apple //e or a Commodore 64 when an IBM-PC is available?"
uso, how can you even talk about BASIC and C in the same sentence? That's
awful...and you mentioned Zolman's Hi-Tech C for the Z80 earlier in this
thread but that didn't have floating point support either...
I'm obviously the only C programmer in this ng that likes using a plain old
K&R compiler with floating point support.
Bill Buckels
Bill Buckels
Lars Haugseth
Ask the descendants/inheritors of Charles Goodyear, John Dunlop,
André Michelin, Giovanni Battista Pirelli et al. Or any of the
race car drivers using their inventions (including Maurice Randall,
oops, back on-topic, sorry!) ;-)
--
Lars Haugseth
J. Robertson
wrote:
>When I tried CC65 the snapshot was broken. Aztec C wasn't broken and I just
>continued to use what worked for me.
Understandable.
> That was quite some time (a year or so) ago and maybe CC65 would work for me now.
Probably would I'd imagine. This reminds me, I haven't updated to the
newest version in some time.
>I was never under the misimpression that CC65 was a native mode compiler,
Got it. :-)
>but when I wrote the cross-compiler article on Wikipedia I must confess that
>I did not even mention CC65 but I certainly mentioned Aztec C.
Heh, of course. You advertise Aztec C quite enough that you should
receive some compensation from the past developers. ;-)
>And Microsoft C.
I've always been a Borland user. Hey! Don't start calling me Harry
Potter now! :-P
>What is it you are saying exactly Jason? Are you really another of these
>CC65 munchkins of the great Oz's??? <g>
Yeah, I'm one of the CC65 munchkins, lol. Been following the
development since Ullrich started working on it.
> or are you going to say something besides making fun of me.
Your statement of "smarter people wrote [Aztec C]" triggered a
momentary flashback to another user here years back who assumed and
insisted that everyone used the assembler he wrote. He'd insult and
challenge those people who used something else (it was inconceivable
to him that they would). So my response was an old knee-jerk reaction.
;-) At least you haven't claimed yet that icons on a desktop should
jump away from the mouse cursor like he had a few times. ;-)
>Remember that my initial position is that K&R is not bad if the compiler is
>good and since Aztec C works well for me I don't see much advantage to ANSI.
I've never thought about the whole K&R vs ANSI thing before
truthfully. For me if I'm using a compiler that just supports K&R I
have no problem following that. For a compiler that supports both I do
tend to go the ANSI C path as I am more used to that style.
Anyway, what I'll do is I'll download Aztec C for the C64 (Yeah, yeah,
I know it's not a native compiler. ;-) ) and play around with it. It's
doubtful I'll convert but I'll try it. :-)
Looking at the Aztec Museum page I have to say I may have an interest
in the Aztec CZ80 compiler at some point. :-)
Jason
Bill Buckels
"J. Robertson" <jk...@juno.com> wrote:
>I've always been a Borland user. Hey! Don't start calling me Harry Potter
>now! :-P
Jason, in 1992 I bought Borland C++ 3.1 and Microsoft C++ 7.0 and learned to
write Windows code using OWL and the standard Microsoft API both.
I had always used both Turbo C and Microsoft C in MS-DOS as well.
Even though many of my gigs have been working for Microsoft Partners and
even though I have been a Microsoft Partner myself I have also been (in 2001
and 2002) a Borland (Inprise) Partner although never fond of Delphi nor
Pascal.
I have many of the Borland compilers here installed on this box as well as
Microsoft and many others which leads to my final statement on this
subject... it takes more than a Borland compiler to be Harry Potter...
Bill Buckels
"Lars Haugseth" <nj...@larshaugseth.com> wrote:
>* "Bill Buckels" <bbuc...@mts.net> wrote:
>> Why reinvent the wheel?
>Ask the descendants/inheritors of Charles Goodyear, John Dunlop, Andr�
>Michelin, Giovanni Battista Pirelli et al.
$$$$
>Maurice Randall
$
CC65
!($)
Lars Haugseth
>
> "Lars Haugseth" <nj...@larshaugseth.com> wrote:
>
>>* "Bill Buckels" <bbuc...@mts.net> wrote:
>
>>> Why reinvent the wheel?
>
>
> $$$$
>
>>Maurice Randall
>
> $
>
> CC65
>
> !($)
True, but you either missed or chose to ignore the point about
making something better than what's currently available.
--
Lars Haugseth
Bill Buckels
"Lars Haugseth" <nj...@larshaugseth.com> wrote:
>True, but you either missed or chose to ignore the point about making
>something better than what's currently available.
"If anyone disagrees with anything I say, I am quite prepared not only to
retract it, but also to deny under oath that I ever said it." -Tom Lehrer
Another case in point that you should consider:
http://www.teacherschoice.ca/irish/index.htm
I have also heard from Airship that Norway is really in Nebraska.
Actually Lars, I have done more "to make something better than what's
currently available" to a greater degree than many people that I can think
of whether it comes to making vintage compilers available or even outside of
vintage computing and computing in general in such areas as healthcare
advocacy and volunteerism.
To begin with I have written millions of lines of shareware and freeware
beginning in the 1980's.
Remember too that the Aztec C Museum Website did not exist and the
cross-compilers on that site were considered extinct before I decided to
share with the world a couple of years ago at my expense. The link libraries
and other tools that I provided and still do are part of a substantial
effort to make things better for vintage computing folks despite
chicken-brained comments from shit-eating hens.
It is easy to ignore chickens that do virtually nothing but peck and
comments like yours when I have done so much more as a public service out of
the kindness of my heart donating countless hours and other resources over
several decades.
Just go ahead and review the compiler bundles that I have made available
before you consider to freely disgregard the fact that I gave you any easy
way-out on my last reply to your bird poop.
Fortunately for me my skin is not so thin but OTOH fortunately for you
despite the fact that my tongue is sharp and forked the Aztec C website is
easy to find as are some of my other Vintage computing efforts and you may
even find a little Ruby reference if you search a little:
http://www.aztecmuseum.ca/
http://www.aztecmuseum.ca/links/
http://www.c64classics.ca/index.htm#graphics
http://www.cpm8680.com/dsktool/
http://en.wikipedia.org/wiki/User:Bill_Buckels
Or perhaps you prefer:
Bill Buckels
winstonsmith
> "Lars Haugseth" <n...@larshaugseth.com> wrote:
> >True, but you either missed or chose to ignore the point about making
> >something better than what's currently available.
>
> "If anyone disagrees with anything I say, I am quite prepared not only to
> retract it, but also to deny under oath that I ever said it." -Tom Lehrer
>
> Another case in point that you should consider:
>
> http://www.teacherschoice.ca/irish/index.htm
>
> I have also heard from Airship that Norway is really in Nebraska.
>
> Actually Lars, I have done more "to make something better than what's
> currently available" to a greater degree than many people that I can think
> of whether it comes to making vintage compilers available or even outside of
> vintage computing and computing in general in such areas as healthcare
> advocacy and volunteerism.
>
> To begin with I have written millions of lines of shareware and freeware
> beginning in the 1980's.
>
> Remember too that the Aztec C Museum Website did not exist and the
> cross-compilers on that site were considered extinct before I decided to
> share with the world a couple of years ago at my expense.
<snip>
My only lament is that Aztec C does not exist for other micros
(mainly, the TI-99) *sigh*
It would be nice to have at least a *decent* C compiler, and not one
based on small-C.
commodorejohn
> "Lars Haugseth" <n...@larshaugseth.com> wrote:
> >True, but you either missed or chose to ignore the point about making
> >something better than what's currently available.
> Actually Lars, I have done more "to make something better than what's
> currently available" to a greater degree than many people that I can think
> of whether it comes to making vintage compilers available or even outside of
> vintage computing and computing in general in such areas as healthcare
> advocacy and volunteerism.
Uh, the point there wasn't to say who has the more retrocomputing
brownie points. The point was that there *is* a point to "reinventing
the wheel;" to see if you can't improve upon an existing product.
Whether or not you personally like CC65, there *is* a perfectly fine
reason for its existence.
Garberstreet Electronics
"Bill Buckels" <bbuc...@mts.net> wrote in message
news:_AVbm.69848$YU5....@newsfe21.iad...
That's great. Can get to everything from there.
And, on the subject of what people are trying to say,
It's not that you don't do anything, or have something
good in Aztec-C, that's a given, it is that you tend
to 'tout' ( definition 4 in Merriam-Webster online )
your own horn quite a bit, much more than even I can
stand, and although you have a right, it's nonbefitting
someone who has done such great things over so many
years. Plus, the more you try, the less folks will hear.
Don't you agree, Bill? Let your work speak for you.
Garberstreet Electronics
http://www.garberstreet.com
Groepaz
> I've never thought about the whole K&R vs ANSI thing before
> truthfully. For me if I'm using a compiler that just supports K&R I
> have no problem following that. For a compiler that supports both I do
> tend to go the ANSI C path as I am more used to that style.
there are quite some technical reasons to prefer ansi-c too, especially in
small/embedded environments... one that should be kinda obvious is the
implicit int stuff in k&r, which means that the compiler often has no
chance to tell if a function actually takes an argument or returns a value,
and then generates the required code even if it is not needed. (the
ansi-c "void" keyword fixes that). a similar problem exists because of
absence of proper function prototypes. etc :)
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
Ein kluger Mann widerspricht seiner Frau nicht. Er wartet bis sie es selbst
tut.
Groepaz
> True, but you either missed or chose to ignore the point about
> making something better than what's currently available.
like the dhrystone.c someone posted in this thread:
MACHINE ￜ ￜ MICROPROCESSOR ￜ ￜ ￜOPERATING ￜ ￜ ￜ
COMPILER ￜ ￜ ￜDHRYSTONES/SEC.
TYPE ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜSYSTEM ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜNO REG ￜ ￜREGS
--------------------------ￜￜￜￜￜￜ------------ￜￜￜￜ-----------ￜￜￜￜￜ---------------
Commodore 64 ￜ6510-1Mhz ￜ ￜ ￜ C64 ROM ￜ ￜ ￜ ￜ C Power 2.9 trim ￜ ￜ19 ￜ ￜ 34
Commodore 64 ￜ6510-1MHz ￜ ￜ ￜ C64 ROM ￜ ￜ ￜ ￜ C Power 2.8 ￜ ￜ ￜ ￜ 36 ￜ ￜ 36
Apple IIe ￜ ￜ 65C02-1.02Mhz ￜ DOS 3.3 ￜ ￜ ￜ ￜ Aztec CII v1.05i ￜ ￜ37 ￜ ￜ 37
Commodore128 ￜ8502-2Mhz ￜ ￜ ￜ C128 ROM ￜ ￜ ￜ ￜC Power 128 ￜtrim ￜ 43 ￜ ￜ 68
Commodore 64 ￜ6510-0.98MHz ￜ ￜC64 ROM ￜ ￜ ￜ ￜ cc65 2.12.9 ￜ ￜ ￜ ￜ 50 ￜ ￜ 52
Home Brew ￜ ￜ Z80-4.00Mhz ￜ ￜ CPM-80 ￜ ￜ ￜ ￜ ￜHisoft C++ ￜ ￜ ￜ ￜ ￜ53 ￜ ￜ 53
Home Brew ￜ ￜ Z80-2.5Mhz ￜ ￜ ￜCPM-80 v2.2 ￜ ￜ Aztec CII v1.05g ￜ ￜ91 ￜ ￜ 91
Commodore128 ￜ8502-2Mhz ￜ ￜ ￜ C128 ROM ￜ ￜ ￜ ￜcc65 2.12.9 ￜ ￜ ￜ ￜ100 ￜ ￜ105
... kinda speaks for itself :) i'd really like to see some numbers for
hitech-c, couldnt find any unfortunately... and i am still very curious
about how WDCs own compiler performs, but it looks like that one isn't even
available for sale for normal people, bah. did anyone ever see this one or
even worked with it?
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
There are 10**11 stars in the galaxy. That used to be a huge number. But
it's only a hundred billion. It's less than the national deficit! We used
to call them astronomical numbers. Now we should call them economical
numbers.
<Richard Feynman>
winstonsmith
> Lars Haugseth wrote:
> > True, but you either missed or chose to ignore the point about
> > making something better than what's currently available.
>
> like the dhrystone.c someone posted in this thread:
>
> COMPILER DHRYSTONES/SEC.
> TYPE SYSTEM NO REG REGS
> -------------------------- ------------ ----------- ---------------
> Commodore 64 6510-1Mhz C64 ROM C Power 2.9 trim 19 34
> Commodore 64 6510-1MHz C64 ROM C Power 2.8 36 36
> Apple IIe 65C02-1.02Mhz DOS 3.3 Aztec CII v1.05i 37 37
> Commodore128 8502-2Mhz C128 ROM C Power 128 trim 43 68
> Commodore 64 6510-0.98MHz C64 ROM cc65 2.12.9 50 52
> Home Brew Z80-4.00Mhz CPM-80 Hisoft C++ 53 53
> Home Brew Z80-2.5Mhz CPM-80 v2.2 Aztec CII v1.05g 91 91
> Commodore128 8502-2Mhz C128 ROM cc65 2.12.9 100 105
>
> ... kinda speaks for itself :) i'd really like to see some numbers for
> hitech-c, couldnt find any unfortunately... and i am still very curious
> about how WDCs own compiler performs, but it looks like that one isn't even
> available for sale for normal people, bah. did anyone ever see this one or
> even worked with it?
>
A similar list appears to be: http://www-aix.gsi.de/~kraemer/COLLECTION/dhryst.txt
and has the same C64 time at the top of the list by performance.
There are a lot of systems that should perform better toward the
bottom, but no description of what the unit or measurement is. I'd
think a higher number would be better simply because the C64 version
had a higher number using registers than without.
It has been a decade since I played with this benchmark on a PC.
winstonsmith
Ok, from Wikipedia:
Dhrystone tries to represent the result more meaningfully than MIPS
(million instructions per second), because MIPS cannot be used across
different instruction sets (e.g. RISC vs. CISC) for the same
computation requirement from users. Thus, the main score is just
Dhrystone loops per second. Another common representation of the
Dhrystone benchmark is the DMIPS (Dhrystone MIPS) obtained when the
Dhrystone score is divided by 1,757 (the number of Dhrystones per
second obtained on the VAX 11/780, nominally a 1 MIPS machine).
So the C64 is the worst performer on this list using "C Power 2.9
trim".
Hmm, that's not good. Think I know a machine or two that could top
that list!
Groepaz
> So the C64 is the worst performer on this list using "C Power 2.9
> trim".
yes, power-c performs pretty bad. but compare it to the results of aztec-c
and cc65 :)
> Hmm, that's not good. Think I know a machine or two that could top
> that list!
uh thats not the point, you can find a long list of machines that perform
better in the dhrystone.c code (obviously)... i only picked the ones which
are roughly in the same range as the c64. the point is to compare how
different compilers perform on (nearly) the same machines :)
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
People can be divided into three groups: Those who make things happen, those
who watch things happen, and those who wonder what happened.
<John W. Newbern>
winstonsmith
> winstonsmith wrote:
> > So the C64 is the worst performer on this list using "C Power 2.9
> > trim".
>
> yes, power-c performs pretty bad. but compare it to the results of aztec-c
> and cc65 :)
>
> > Hmm, that's not good. Think I know a machine or two that could top
> > that list!
>
> uh thats not the point, you can find a long list of machines that perform
> better in the dhrystone.c code (obviously)... i only picked the ones which
> are roughly in the same range as the c64. the point is to compare how
> different compilers perform on (nearly) the same machines :)
>
No, I mean to make the C64 with power-c look better ;)
Groepaz
>
> No, I mean to make the C64 with power-c look better ;)
no need to, really, i dont think there is anyone left on earth who doesnt
think power-c is crap :)
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
Never underestimate the bandwidth of a station wagon full of tapes hurtling
down the highway
<Andrew S. Tanenbaum>
Laust Brock-Nannestad
> there are quite some technical reasons to prefer ansi-c too, especially in
> small/embedded environments... one that should be kinda obvious is the
> implicit int stuff in k&r, which means that the compiler often has no
> chance to tell if a function actually takes an argument or returns a value,
> and then generates the required code even if it is not needed. (the
> ansi-c "void" keyword fixes that).
Actually, in those two cases, the compiler should have no problems
figuring whether parameters are used or not, even without the use of
void.
If a call to a function never appears as part of an assignment or in a
subexpression, then the return value of that function is never used and
can safely be optimized away. Likewise, if a parameter given in a
function call is never used inside the function, then it can discarded
as well. There's no need to pass it to the function when called.
In any case, prototypes and the saner function-declaration syntax of
ANSI-C, are excellent reasons for preferring a newer compiler, not to
mention the advancements in compiler technology, that must have happened
since the 80's :-)
Regards,
Laust
Groepaz
> Groepaz <gro...@gmx.net> wrote:
>
>> there are quite some technical reasons to prefer ansi-c too, especially
>> in small/embedded environments... one that should be kinda obvious is the
>> implicit int stuff in k&r, which means that the compiler often has no
>> chance to tell if a function actually takes an argument or returns a
>> value, and then generates the required code even if it is not needed.
>> (the ansi-c "void" keyword fixes that).
>
> Actually, in those two cases, the compiler should have no problems
> figuring whether parameters are used or not, even without the use of
> void.
>
> If a call to a function never appears as part of an assignment or in a
> subexpression, then the return value of that function is never used and
> can safely be optimized away. Likewise, if a parameter given in a
> function call is never used inside the function, then it can discarded
> as well. There's no need to pass it to the function when called.
yes, theoretically :) now think again - the compiler rarely "sees" the
entire program. think of the standard library. or think of a bigger program
that you must split into several chunks so you can even compile it (very
common with many k&r compilers, which have often limited memory available).
that said, the compiler isnt even *allowed* to optimize away such things,
since calling convention must be met even in the binary representation.
(ok, then again, things like a defined ABI didnt exist in K&R times anyway
=P)
> In any case, prototypes and the saner function-declaration syntax of
> ANSI-C, are excellent reasons for preferring a newer compiler, not to
> mention the advancements in compiler technology, that must have happened
> since the 80's :-)
yep :)
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
Three things are certain: Death, Taxes, and lost Data.