Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Other C64/128 C compilers?

502 views
Skip to first unread message

Harry Potter

unread,
Jan 11, 2013, 12:18:43 PM1/11/13
to
I have Turbo C, Power C 64/128 and cc64. Cc64 sem

Harry Potter

unread,
Jan 11, 2013, 12:23:56 PM1/11/13
to
Pressed the wrong button! Sorry! :( Of course, the keyboard on which I'm working is faulty! :(

I have Turbo C, Power C 64/128 and cc64. Cc64 has a nasty bug with global variables, and I haven't gotn around to using the others. I'm looking to progamming on a _real_ C64/128--or at least on the emulators. Where can i find such?

rusure

unread,
Jan 11, 2013, 12:54:49 PM1/11/13
to
On Friday, January 11, 2013 10:23:56 AM UTC-7, Harry Potter wrote:
> Pressed the wrong button! Sorry! :( Of course, the keyboard on which I'm working is faulty! :(
>
>
>
> I have Turbo C, Power C 64/128 and cc64. Cc64 has a nasty bug with global variables, and I haven't gotn around to using the others. I'm looking to progamming on a _real_ C64/128--or at least on the emulators. Where can i find such?

I think ABACUS may have had a PASCALE but I sold mine to probably a Canadian. He sent me a $20 bill USD in the mail. That doesn't happen frequently.

Payton Byrd

unread,
Jan 11, 2013, 3:13:17 PM1/11/13
to
On Friday, January 11, 2013 11:18:43 AM UTC-6, Harry Potter wrote:
> I have Turbo C, Power C 64/128 and cc64. Cc64 sem

http://www.lyonlabs.org/commodore/powerc.html

Groepaz

unread,
Jan 12, 2013, 4:24:48 AM1/12/13
to
what nasty bug that noone else but you encountered would that be?

and i very much doubt you will have a lot of success with doing what you did
on cc65 with a compiler like power-c. cc65 is lightyears ahead regarding
stability and featureset. (power-c is K&R to begin with...)

--

http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org

I am lucky I am such a bad ass. When my gf whines about all my c64s, i just
look her in the eyes and say: "Never ask me to choose between them and you".
<Hedning/G*P>


Harry Potter

unread,
Jan 14, 2013, 10:08:53 AM1/14/13
to gro...@gmx.net
The bug I mentioned with cc64 is mentioned in documented in its docs, and you're right about the stability. I'd just like to play with the K&R C/nostalgia style.

Groepaz

unread,
Jan 15, 2013, 1:10:41 AM1/15/13
to
Harry Potter wrote:

> The bug I mentioned with cc64 is mentioned in documented in its docs

could you give a link? i have used cc65 quite a lot and never knew about
such bug (or encountered it).
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>


Harry Potter

unread,
Jan 15, 2013, 8:56:51 AM1/15/13
to gro...@gmx.net
The bug is with cc64, not cc65. I can't find it on the internet anymore. :(

paskali

unread,
Feb 12, 2013, 3:58:07 PM2/12/13
to
Harry Potter <rose.j...@yahoo.com> wrote:

> I have Turbo C, Power C 64/128 and cc64. Cc64 sem
>
There is Abacus-C, too. I use it and works great.

http://commodore64.wikispaces.com/Programming+languages

The Power-c has some bugs, i suggest you to avoid it.

C on Commodore 64 may be a good choice for small or middle source codes in
replacement of the interpreted basic; Abacus C has library that make able
you to play with graphic and sprites very well and very easy. However, if
you need performance and full hardware control the only choice is the
assembly; with C is possible to mix the two codes; however it is suggest
to use the last one only.

--
http://www.webuse.net/pm.php?u=2970

Posted using www.webuse.net

Brendan Robert

unread,
Feb 12, 2013, 4:39:00 PM2/12/13
to
Aztec C was fairly popular in the Apple world. Did the C64 port ever catch on with any notoriety?

-B

Groepaz

unread,
Feb 12, 2013, 5:21:03 PM2/12/13
to
Brendan Robert wrote:

> Aztec C was fairly popular in the Apple world. Did the C64 port ever
> catch on with any notoriety?

it also exists as a crosscompiler for the c64, see
http://www.aztecmuseum.ca/

however, these days there really is little reason to use any other compiler
than cc65 (unless you insist on using an old historic compiler ofcourse).
they all produce far worse code, have a lot of bugs, are slow, have very
incomplete libraries, usually dont support any form of half modern C
standard, etc etc.
You think you know when you learn, are more sure when you can write, even
more when you can teach, but certain when you can program.
<Alan J. Perlis>


paskali

unread,
Feb 13, 2013, 5:55:55 AM2/13/13
to
Groepaz <gro...@gmx.net> wrote:
> it also exists as a crosscompiler for the c64, see
> http://www.aztecmuseum.ca/
>
> however, these days there really is little reason to use any other compiler
> than cc65 (unless you insist on using an old historic compiler ofcourse).
> they all produce far worse code, have a lot of bugs, are slow, have very
> incomplete libraries, usually dont support any form of half modern C
> standard, etc etc.
>
The best way to program for c64 is assembly on c64. The native c compilers may
be a good choice to avoid basic, if anyone does not want (or does not know) to
use assembly.

Harry Potter

unread,
Feb 13, 2013, 9:18:31 AM2/13/13
to
Granted, C is a good relacement for BASIC. I really was toying around with creating C64/128 software on a C64/128. I started creating a game with BASSEM :) but never finished it :( . I was also toying aroung with creating my own C compilers: one cross-platform and one on and for each of several 6502 targets. The cross-platform one has a nasty bug to fix before I continue, and the others never got off the ground. I even want to create a UPL/Quetzalcoatl-like compiler, but I'm just thinking about it. BTW, I plan the cross-platform C compiler to have alot of optimizations and tools to make code beter and more efficient. What do you think?

paskali

unread,
Feb 14, 2013, 6:41:55 AM2/14/13
to
C is an "old" language that was born when the c64 was not jet. It was planned to
avoid (or to mix with) assembly, especially on 16bit processors but also on
8bit. You should be able to make a native c-compiler for 6502/6510 and to
get good results; remember the limited resources, of course.
The cross compiler has the only advances to run on better machine and therefore
to work on more big resources that native does not have; you will be able to
compile and test more fast. However the results may be the same.

Harry Potter

unread,
Feb 14, 2013, 9:08:03 AM2/14/13
to
Thank you, paskali. You made my day! :)

Groepaz

unread,
Feb 15, 2013, 1:50:18 AM2/15/13
to
Harry Potter wrote:

> I was also toying aroung with
> creating my own C compilers: one cross-platform and one on and for each of
> several 6502 targets. The cross-platform one has a nasty bug to fix
> before I continue, and the others never got off the ground. I even want
> to create a UPL/Quetzalcoatl-like compiler, but I'm just thinking about
> it. BTW, I plan the cross-platform C compiler to have alot of
> optimizations and tools to make code beter and more efficient. What do
> you think?

seriously? i think that you didnt actually ever create anything that even
vaguely resembles a working C compiler, native or not.
The day Microsoft creates a product that doesn't suck is the day they make
vacuum cleaners.


Groepaz

unread,
Feb 15, 2013, 1:53:33 AM2/15/13
to
paskali wrote:

> Groepaz <gro...@gmx.net> wrote:
>> it also exists as a crosscompiler for the c64, see
>> http://www.aztecmuseum.ca/
>>
>> however, these days there really is little reason to use any other
>> compiler than cc65 (unless you insist on using an old historic compiler
>> ofcourse). they all produce far worse code, have a lot of bugs, are slow,
>> have very incomplete libraries, usually dont support any form of half
>> modern C standard, etc etc.
>>
> The best way to program for c64 is assembly on c64. The native c compilers
> may be a good choice to avoid basic, if anyone does not want (or does not
> know) to use assembly.

i wouldnt say that assembly is always the best way - actually cc65 is good
enough for a lot of stuff - there is little reason to write something like a
wordprocessor or a copy program completely in assembly, when you could do
95% of it using C easily.

as for native compilers, i would generally advice against them these days
for the reasons mentioned. it will save you a lot of frustration if you dont
have to deal with each compilers different strange quirks and problems. IF
it has to be a native compiler running on c64, i would recommend using a
pascal compiler instead - they typically produce better code and have less
funny bugs.
Das Blockieren oder Filtern bestimmter Internet-Inhalte ist für die
Europäische Union völlig inakzeptabel.
<Viviane Reding, EU-Medienkommissarin, geschrieben ins Stammbuch der
chinesischen Regierung im Juni 2009>


Harry Potter

unread,
Feb 15, 2013, 10:20:42 AM2/15/13
to gro...@gmx.net
Groepaz: It is true that I didn't yet invent a C compiler *yet*. As of now, it has a serious bug in it that I need to work out.

I also agree that most software doesn't need assembler. Assembler is mostly good for video games and some OS and hardware/data operations.

Silver Dream !

unread,
May 28, 2013, 9:08:41 AM5/28/13
to
On 2013-02-15 07:53:33 +0100, Groepaz said:

> as for native compilers, i would generally advice against them these days
> for the reasons mentioned. it will save you a lot of frustration if you dont
> have to deal with each compilers different strange quirks and problems. IF
> it has to be a native compiler running on c64, i would recommend using a
> pascal compiler instead - they typically produce better code and have less
> funny bugs.

Which one would you recommend in the first place?

--
SD!

Harry Potter

unread,
May 28, 2013, 11:32:30 AM5/28/13
to
My main reason for using a native compiler is nostalgia. I just think it fun to work on the original equipment--or at least emulators of such. That's it! ;) What do you think?

Bill Buckels

unread,
May 28, 2013, 8:37:56 PM5/28/13
to
"Harry Potter" <rose.j...@yahoo.com> wrote:

> What do you think?

http://en.wikipedia.org/wiki/Cross_compiler


http://en.wikipedia.org/wiki/Aztec_C

A vintage C Cross-Compiler with many examples ... an old but functional K&R
compiler in the flavour of the day that targets old but functional systems.
Even then, the C64 was too slow for native mode development. Pascal was
wirthy enough shake the tuition from the pockets of rich parents, but when
we were offered their kids in the work place we politely refused unless they
could demonstrate C and Assembly language skills....

Manx Aztec C65
Version 1.06e
Target: Commodore 64 6502 Native Code
Target OS: Commodore 64 (C64) BASIC 2 operating system
Compiler: C II Vers. 1.05h 6502 (C) 1982, 1983 by Manx Software Systems

MS-DOS cross-development environment for 8086 and compatible computers
Preconfigured for Windows XP

With several samples, projects, and a production example.
With an additional link library for sound and graphics etc.
With many original related custom tools for including source code

Here's a link to get it:

http://www.aztecmuseum.ca/

And here's another few to show you what it can do (if you are someone who
can demonstrate C and Assembly language skills and who understands that
performance is not tied to the metrics of speed and size and modern syntax,
or sadly we would not be interested in the past in the first place... just
modern compilers):

http://www.c64classics.ca/
http://www.appleoldies.ca/
http://www.cpm8680.com/

Aztec C is for folks who want to connect with the past.

There is at least one other cross-compiler available for the 6502 machines
including the C64 and the Apple II, but the environment is too modern to
provide a genuine vintage experience...

That is just what I think (thanks for asking).

All the best,

Bill




Hg

unread,
May 29, 2013, 1:04:03 AM5/29/13
to
The situation may have changed now but the last time I checked almost
every major software package for Intel compatible systems was written
in C or C++.
I guess it's extremely unlikely though I was wondering if any
commercial software written in C was released for the 64/128 back
in the day?

--
T

Bill Buckels

unread,
May 29, 2013, 6:58:18 AM5/29/13
to

"Hg" <H...@Hg.Hg> wrote:

> I guess it's extremely unlikely though I was wondering if any commercial
> software written in C was released for the 64/128 back in the day?

I thought back then that most major C64 applications were written in
assembly language but I haven't thought much about it since. I have no
proof but I doubt if many were written using C.

For my part, I resurrected the Aztec CII C64 Cross-compiler for the fun of
"pretending" I was an MS-DOS C developer back in the early '80's writing
programs for the Commodore 64. But I really doubt that many copies of the
Aztec C compiler for the Commodore 64 were sold...

Regardless, while this "resurrection" was done for a rather simplistic
reason, I had great fun doing so and highly recommend the experience of
using this old compiler for anyone who can write in C and Assembler. You
might even call doing so playing a computer game called "C64 C
Programmer"... great fun as I say:)

I really wish I had more Aztec C compilers set-up for the Commdore 64 to add
to my museum.

Bill


Harry Potter

unread,
May 29, 2013, 9:14:38 AM5/29/13
to
I once actually tried Aztec C/C64. However, a simple Hello, World application took ~11k. For that reason, I stopped using it. Right now, I use cc65 instead. I am currently "working" on a new cross-platform C compiler to handle the pitfalls with cc65. I'd also like to try out *native* compilers for CBM and Apple 2 targets. Thank you for responding.

Groepaz

unread,
May 29, 2013, 1:12:47 PM5/29/13
to
C and pascal were both used, mostly for wordprocessor or database type of
applications. much more often you can find compiled basic though :)
Love conquers all except poverty and toothache.
<Mae West>


Groepaz

unread,
May 29, 2013, 1:14:40 PM5/29/13
to
it was like 1988 that i last used one, so.... uhm =) not sure if i'd want to
recommend any specific one. i'd probably pick the one that comes with a lot
of documentation and c64 specific examples =)
If you are not paying for it, you are not the customer. You are the product
being sold.


Bill Buckels

unread,
May 29, 2013, 2:33:04 PM5/29/13
to

"Harry Potter" <rose.j...@yahoo.com> wrote:
> I once actually tried Aztec C/C64. However, a simple Hello, World
> application took ~11k.

So what did a full-blown application with overlays take? Or did you not work
your way through the examples and full-blown programs that I provided with
the compiler? If all you are looking at is program size then use machine
code... C is not for you.

> For that reason, I stopped using it.

You never really used it anyway Joseph. You just installed it as far as I
know and then wrote maybe a line or two of code. I can't really call that
using the compiler. To me, using a compiler takes quite a block of time...
something like what I did. About a year or sdo of man-days for an expert
programmer. To do anything less is not taken seriously by people like me who
actually work through a machine and exercise it with all sorts of fun stuff
to see what we can do.

> Right now, I use cc65 instead.

How is that going?

> I am currently "working" on a new cross-platform C compiler to handle the
> pitfalls with cc65.

I don't think cc65 has pitfalls. It writes tight small code but it's really
a modern compiler and not old-fashioned at all. That's one of my reasons for
not bothering much with it. When I did bother with it it was on the Apple
IIe, and it worked flawlessly for me.

I am aware of course that you had issues with mapping of the arrow keys on
the Apple, but that matter could have been resolved if the maintainers had
paid attention to you I think. Unfortunately (although I agree that cc65 has
a bug that you found) it was hardly a serious bug and since cc65 is
primarily a C64 phenomenom an Apple II bug doesn't matter much... I haven't
seen many cc65 on the Apple II except by a handful of people who seem to
really know how to use the compiler, or so it seems The fact that the
keyboard bug doesn't bother them says something, but I don't know what.
Maybe they don't write applications that use arrow keys. But even old
compilers have bugs, and we just work around them, so maybe they work around
the chr$127 issue...

> I'd also like to try out *native* compilers for CBM and Apple 2 targets.

If it's native mode C compilers in ProDOS 8 on the Apple IIe which ones
would you try? Aztec C 3.2b comes to mind.

If it's native mode C compilers in DOS 3.3 on the Apple IIe which ones would
you try? Aztec CII comes to mind.

I assume you would use Power C on the C64.

Would you use Orca C on the Apple GS? That's a pretty nice compiler, but you
still need to buy a licenced copy... would you pay for a licenced copy?

Would you also code for CP/M 80 on the Apple II or C64? If so which
compilers would you try? Aztec C comes to mind.

Like I said, the C64 and Apple II are both to much trouble when bothering
with native mode compilers... they always were for me which is why I bought
Aztec C's MS-DOS cross-compilers when I actually got paid for programming on
those old platforms.

Besides the fact that they ran quickly in MS-DOS, my reason for selecting
them was belive it or not small code size, as well as good documentation.
Also because I had good success with Aztec C in MS-DOS, but the price was
high back then. Around $1000 Canadian per compiler I seem to remember.

Bill


Peter Schepers

unread,
May 29, 2013, 2:54:00 PM5/29/13
to

> So what did a full-blown application with overlays take? Or did you not work
> your way through the examples and full-blown programs that I provided with
> the compiler? If all you are looking at is program size then use machine
> code... C is not for you.

I recall years ago when I was experimenting with the various BASIC
compilers to see what they couldn't do and their relative speeds. Each
one had specific limitations, but also had specific overhead, i.e. the
default libraries supplied were always the same size and sometimes quite
large. Once your program was large enough, the compiled version was
smaller than your source. Sounds like the overhead for C is similar. If
you have a large enough project, the overhead might not be so bad.

Personally, assembler was always way more fun.

PS

SD!

unread,
May 29, 2013, 3:29:40 PM5/29/13
to
On 2013-05-29 19:14:40 +0200, Groepaz said:

>>> as for native compilers, i would generally advice against them these days
>>> for the reasons mentioned. it will save you a lot of frustration if you
>>> dont have to deal with each compilers different strange quirks and
>>> problems. IF it has to be a native compiler running on c64, i would
>>> recommend using a pascal compiler instead - they typically produce better
>>> code and have less funny bugs.
>>
>> Which one would you recommend in the first place?
>
> it was like 1988 that i last used one, so.... uhm =) not sure if i'd want to
> recommend any specific one. i'd probably pick the one that comes with a lot
> of documentation and c64 specific examples =)

I honestly asked because I remeber seeing only one, which didn't really
work so if you (or anyone) have some recommendations for a well working
one - that would be interesting to have a look at.

--
SD!

SD!

unread,
May 29, 2013, 3:34:33 PM5/29/13
to
On 2013-05-29 15:14:38 +0200, Harry Potter said:

> I am currently "working" on a new cross-platform C compiler

Why did you use quotation marks.. aa... never mind ;-)

> to handle the pitfalls with cc65.

Like the lack of float types?

--
SD!

Bill Buckels

unread,
May 29, 2013, 7:05:40 PM5/29/13
to

"Peter Schepers" <sche...@uwaterloo.ca> wrote:

> I recall years ago when I was experimenting with the various BASIC
> compilers to see what they couldn't do and their relative speeds.

Aztec CII's cross-compiler for the C64 runs slower than CC65 which is a
modern compiler. However considering that Aztec CII is 30 years old and CC65
is a modern compiler, running at 70-80% of the speed of CC65 is not bad.

Aztec C was consistent across platforms including CP/M 80 and CP/M 86, the
Apple II and MS-DOS in 1982-83. They did pretty well being one of the
first... and provided an environmnet that their programmers expected in
those Pre-ANSI/ISO years. It's much easier to improve on something than to
do it in the first place, but more importantly it is much harder to provide
a run-time that provides features like a floating point library and math
functions and overlay support when you are among the first.

> Each one had specific limitations, but also had specific overhead, i.e.
> the default libraries supplied were always the same size and sometimes
> quite large. Once your program was large enough, the compiled version was
> smaller than your source. Sounds like the overhead for C is similar.

Not exactly, but that is almost the idea. Or it was back then.

> Personally, assembler was always way more fun.

I enjoyed 8086 assembler better because I also had segment registers. Aztec
C allows inline assembler and user registers and the whole-meal deal when it
comes to writing. If one enjoys writing it is a pleasure and a challenge
both.

I don't care a fig if the program is a little larger than a modern compiler.
I just like it better. Others might not prefer the challenge and if that's
the case then there are lots of modern compilers around for lots of
platforms and easy writing. But since I am a C with Assembly programmer I
get a little sick of writing in modern languages after essentially working
in just about every other modern thing for so many years... it's fun to use
the stuff one started with.

Bill


Groepaz

unread,
May 30, 2013, 4:49:20 AM5/30/13
to
Bill Buckels wrote:

>
> "Peter Schepers" <sche...@uwaterloo.ca> wrote:
>
>> I recall years ago when I was experimenting with the various BASIC
>> compilers to see what they couldn't do and their relative speeds.
>
> Aztec CII's cross-compiler for the C64 runs slower than CC65 which is a
> modern compiler. However considering that Aztec CII is 30 years old and
> CC65 is a modern compiler, running at 70-80% of the speed of CC65 is not
> bad.

small-c (http://en.wikipedia.org/wiki/Small-C) is actually of similar age as
aztec-c (http://en.wikipedia.org/wiki/Aztec_C). it is also anything but a
modern compiler, even compared to LCC its software design looks like from
stoneage (it does not even build an internal parse tree, but generates code
on the fly - like all "first generation" c compilers do). so that point is
pretty moot.

what makes cc65 notably different from aztec-c is that it actually is more
or less standard compliant, and comes with a more or less complete and
standard compliant libc. that means you can actually write c code as you are
used from other platforms and then expect the compiler to produce a working
program - without needing any compiler specific hacks and workarounds.
aztec-c on the other hand is a challange for its awkward k&r dialect alone,
and if you are not familiar with the compiler and/or its support libraries
(which are not really libc compatible) then quite a bunch of pitfalls are
waiting for you. and at the end of the day the code it spits out is both
larger and slower than what cc65 gives ya.
Der gesunde Menschenverstand ist eine Sammlung von Vorurteilen, die man bis
zum achtzehnten Lebensjahr erworben hat.
<Albert Einstein>


Bill Buckels

unread,
May 31, 2013, 11:24:43 PM5/31/13
to

"Groepaz" <gro...@gmx.net> wrote:

> aztec-c on the other hand is a challange for its awkward k&r dialect alone

No question it is a challenge... but I would take you to task on
characterizing K&R as awkward... I think it's fun. Nostalgic even. Some
folks prefer a challenge.

But keep in mind that I wrote a whole load of non-trivial library routines
and lots of programs with Aztec C without blinking an eye so perhaps I am no
judge of difficulty for the average joe.

> and if you are not familiar with the compiler and/or its support libraries
> (which are not really libc compatible) then quite a bunch of pitfalls are
> waiting for you.

From my perspective if you aren't much of a C programmer then that is true.
This stuff about libc I don't get either... so what! All I know is that I
put the C64 Aztec C Cross-Compiler and my libraries and utilities together
from a damaged disk-set in about a 3 month period after never looking at it
before.

> and at the end of the day the code it spits out is both larger and slower
> than what cc65 gives ya.

I can't disagree with Apples and Bananas. But with Vice in Warp Mode and
virtually unlimited disk space on my Windows toybox or an SD on my C64 it
really doesn't much matter to me personally. It depends what a guy enjoys...
making some old compiler work is fun, but I do agree it's not for everyone.
Just those of us who enjoy it and can do it.

I realize of course that you can but don't enjoy the old stuff the way I do.

Bill


Groepaz

unread,
Jun 2, 2013, 9:26:06 AM6/2/13
to
Bill Buckels wrote:
>> and if you are not familiar with the compiler and/or its support
>> libraries (which are not really libc compatible) then quite a bunch of
>> pitfalls are waiting for you.
>
> From my perspective if you aren't much of a C programmer then that is
> true. This stuff about libc I don't get either... so what!

bolloks. especially if you are much of a c-programmer, then you are familiar
with the C standard, and the standard set of libraries (such as libc) - and
you'll expect them to work in a certain specific way.

however when using stoneage k&r compiler like aztec-c, all that knowledge is
completely useless at best. more likely it will even get in the way, because
you'll spend a lot of time with finding out why a certain function doesnt do
what it is supposed to do, or with finding out wth it is really doing
instead exactly. (at this point i have more than once ended up writing my
own set of more standard compliant libraries - something that most people
are not willing to do =P)

>> and at the end of the day the code it spits out is both larger and slower
>> than what cc65 gives ya.
>
> I can't disagree with Apples and Bananas. But with Vice in Warp Mode and
> virtually unlimited disk space on my Windows toybox or an SD on my C64 it
> really doesn't much matter to me personally. It depends what a guy
> enjoys... making some old compiler work is fun, but I do agree it's not
> for everyone. Just those of us who enjoy it and can do it.
>
> I realize of course that you can but don't enjoy the old stuff the way I
> do.

well, i find it pretty ridiculous to write programs with an awkward
compiler, get huge bloated code, and then run it in vice in warpmode. if i
write programs for the c64, i want to use them on a real c64 ofcourse. and i
dont care much how the compiler is called or how old it is at all - the one
that produces the best result wins :)
In C++, friends can access each others' private members.


Bill Buckels

unread,
Jun 2, 2013, 11:05:52 PM6/2/13
to

"Groepaz" <gro...@gmx.net> wrote:

> bolloks.

Not at all...

> especially if you are much of a c-programmer, then you are familiar with
> the C standard, and the standard set of libraries (such as libc) - and
> you'll expect them to work in a certain specific way.

Which C Standard? In my 30 years of writing C programs and using hundreds of
compilers and versions in many Unises and Windows and other platforms, I
have
experienced many standards and still do. I have a pretty fair idea what it
takes to be much of a C programmer, and I believe being familiar with your
tools is more important by far than expecting your tools to be perfect and
to some standard or other.

In a perfect world I might expect the expected. Granted, I would expect
compilers to work the way the compiler manual described them, and within the
limitations of the environment and with consideration to the vintage of the
compiler.

> however when using stoneage k&r compiler like aztec-c, all that knowledge
> is completely useless at best.

If you were a newbie I could overlook a statement like that. Standards are
hardly knowledge... just information. If standards is all a programmer has
going for him, then delivering pizza for a living is a good career
alternative. As for stoneage, the C64 and Apple II both predate Aztec C as
does the 6502... so basically what you are saying is it's fine to write code
for a stomeage computer but it's not fine to use a stoneage compiler to do
so... so then where's the fun. I may as well go back to writing Qt
applications for some linux or another... but then I'd choose .NET
applications in Windows anytime for shlock-code! But we're talking about fun
here, and nostalgia!

> more likely it will even get in the way, because you'll spend a lot of
> time with finding out why a certain function doesnt do what it is supposed
> to do, or with finding out wth it is really doing instead exactly. (at
> this point i have more than once ended up writing my own set of more
> standard compliant libraries - something that most people are not willing
> to do =P)

I would rather spend my time writing new libraries than being hung-up on
things being perfect and expecting libc... I can't speak for most people.

> well, i find it pretty ridiculous to write programs with an awkward
> compiler, get huge bloated code, and then run it in vice in warpmode. if i
> write programs for the c64, i want to use them on a real c64 ofcourse. and
> i dont care much how the compiler is called or how old it is at all - the
> one that produces the best result wins :)

I find it pretty ridiculous to talk about winning and about marginal speed
increases on an old computer like my beloved Apples and C64 and C128.

I have already pointed-out that what is awkward to you is awkward to you.
There is nothing wrong with cc65 if that's what you like. I am not going to
sling-mud at it. I find it perfectly usuable, not challenging at all really.
To me it is featureless by comparison to Aztec C and devoid of historical
significance as well. It could be 100% faster and not just 30% faster and
I'd still prefer Aztec C.

Each to their own.

Bill



Groepaz

unread,
Jun 3, 2013, 6:46:31 AM6/3/13
to
Bill Buckels wrote:
>> especially if you are much of a c-programmer, then you are familiar with
>> the C standard, and the standard set of libraries (such as libc) - and
>> you'll expect them to work in a certain specific way.
>
> Which C Standard? In my 30 years of writing C programs and using hundreds
> of compilers and versions in many Unises and Windows and other platforms,
> I have
> experienced many standards and still do.

start with *ANY* standard. K&R isnt really standardized at all, every K&R
compiler is slightly different. thats why they invented ansi-c afterall :)

> I have a pretty fair idea what it
> takes to be much of a C programmer, and I believe being familiar with your
> tools is more important by far than expecting your tools to be perfect and
> to some standard or other.

generally i agree. however, one of the big advantage of using a C compiler
is that they all work pretty much the same.

> If standards is all a programmer has
> going for him, then delivering pizza for a living is a good career
> alternative. As for stoneage, the C64 and Apple II both predate Aztec C as
> does the 6502... so basically what you are saying is it's fine to write
> code for a stomeage computer but it's not fine to use a stoneage compiler
> to do so... so then where's the fun.

i havent said anything like that. if for you the fun lies in hunting down
bugs caused by quirks of K&R, go for it. for me however the fun is in
writing the actual program, and i'd rather take a tool that works as
expected to accomplish that task.

> I would rather spend my time writing new libraries than being hung-up on
> things being perfect and expecting libc... I can't speak for most people.

youd be surprised, most people would rather take existing libraries that
work exactly as advertised. most people dont even want to know how the
compiler works. really.

> I find it pretty ridiculous to talk about winning and about marginal speed
> increases on an old computer like my beloved Apples and C64 and C128.

its not marginal speed increases. its factor 2 to 10, depending on the
actual task. (if aztec-c would actually be capable compiling the bytebench
or dhrystone tests, maybe you could see it =P)

however, much more importantly: the codesize is almost always less. and
memory is very valueable when doing high level stuff on an 8bit micro.

> To me it is featureless by comparison to Aztec C

featureless? the only thing i can see there is the lack of floats. which
isnt really a problem since on 8bit micro you'd want to use fixedpoint
arithmetics for speed reasons most of the time anyway.
Bei Fragen zu diesem Vorgang wenden Sie sich bitte an the administrator of
that system


SD!

unread,
Jun 3, 2013, 8:48:21 AM6/3/13
to
On 2013-06-03 05:05:52 +0200, Bill Buckels said:

> Which C Standard?

ISO/IEC.. with some parts obviously missing.

> If standards is all a programmer has
> going for him, then delivering pizza for a living is a good career
> alternative.

Meaning if I don't want to reimplement e.g. stdio with every project I
should rather buy a scooter.

> does the 6502... so basically what you are saying is it's fine to write code
> for a stomeage computer but it's not fine to use a stoneage compiler to do
> so... so then where's the fun.

In compiling and making run a modern standard C code on an old machine
without rewriting things from scratch for example.
In writing new, modern standard C code for the old machine and seeing
it actually work (!) for another example.

--
SD!

SD!

unread,
Jun 3, 2013, 8:51:41 AM6/3/13
to
On 2013-06-03 12:46:31 +0200, Groepaz said:


>> To me it is featureless by comparison to Aztec C
>
> featureless? the only thing i can see there is the lack of floats.

Yup - that one burns. I think "we" really should move our butts and
implement those, one - preferably not too distant - day.

--
SD!

Bill Buckels

unread,
Jun 3, 2013, 11:37:44 PM6/3/13
to

"SD!" <silv...@wfmh.org.pl.remove.it> wrote:

> In compiling and making run a modern standard C code on an old machine
> without rewriting things from scratch for example.

In Aztec C one does not need to rewrite things from scratch. Perhaps you
should visit the Aztec C Website and the Commodore 64 Classics website and
see for yourself. Perhaps not. Suit yourself...

If you do, also have a look at the Apple II version of Aztec C.

It is amazing that cc65 on the Apple II is, as far as I know, not even
capable of reading or writing files in DOS 3.3, nor as far as I know is it
acpable of even creating a standard SYS program in ProDOS 8. It is not just
floating point support that cc65 lacks on that other platform.

As far as DHRYSTONE, I have those results for v1.1 for Aztec C on the Apple
II. So alot of what has been said here I take as purely converstational...

> In writing new, modern standard C code for the old machine and seeing it
> actually work (!) for another example.

Aztec C's code works fine. Or where did those programs come from?

http://www.aztecmuseum.ca/
Bill


Bill Buckels

unread,
Jun 3, 2013, 11:48:53 PM6/3/13
to

"SD!" <silv...@wfmh.org.pl.remove.it> wrote:
.
> Yup - that one burns.

Obviously there seems not be room for a different opinion here, even from
someone who wrote in C for a living for 30 years. It's not meant to burn...
it's another point of view.

> I think "we" really should move our butts and implement those, one -
> preferably not too distant - day.

On which platforms? To what precision and will you implement floats only or
doubles as well. What about the math library... best have a look at Aztec C
before you start... it might be more work than what it's worth to you.

Bill


silv...@wfmh.org.pl.remove.it

unread,
Jun 5, 2013, 8:49:42 PM6/5/13
to
"Bill Buckels" <bbuc...@mts.net> wrote:
> "SD!" <silv...@wfmh.org.pl.remove.it> wrote:
> .
>> Yup - that one burns.
>
> Obviously there seems not be room for a different opinion here, even from
> someone who wrote in C for a living for 30 years. It's not meant to burn...
> it's another point of view.

The lack of floats problem is a "burning" problem of cc65 IMHO.

>> I think "we" really should move our butts and implement those, one -
>> preferably not too distant - day.
>
> On which platforms?

6502 and some derivatives

> To what precision and will you implement floats only or
> doubles as well.

I don't know. Probably first things first.

>What about the math library... best have a look at Aztec C
> before you start... it might be more work than what it's worth to you.

Ok, but... Where is the fun then? ;-)
--
SD!

Groepaz

unread,
Jun 6, 2013, 8:49:37 AM6/6/13
to
silv...@wfmh.org.pl.remove.it wrote:

>> Obviously there seems not be room for a different opinion here, even from
>> someone who wrote in C for a living for 30 years. It's not meant to
>> burn... it's another point of view.
>
> The lack of floats problem is a "burning" problem of cc65 IMHO.

not sure about that really.... floats are terribly slow on 8bit platforms, i
never really missed them at all - there is nothing you cant do without them
:)

>> To what precision and will you implement floats only or
>> doubles as well.
>
> I don't know. Probably first things first.

its a funny question - because there is only one standard for floats in C =)

and doubles.... jesus. what for?

>>What about the math library... best have a look at Aztec C
>> before you start... it might be more work than what it's worth to you.

changing the libraries that come with aztec-c into something that is halfway
standard compliant and doesnt involve ugly hacks all over the place - now
that is indeed more work than it is worth =P
It is practically impossible to teach good programming to students that have
had a prior exposure to BASIC; as potential programmers they are mentally
mutilated beyond hope of regeneration.
<Edsgar W. Dijkstra>


silv...@wfmh.org.pl.remove.it

unread,
Jun 9, 2013, 5:56:32 PM6/9/13
to
Groepaz <gro...@gmx.net> wrote:

>>> Obviously there seems not be room for a different opinion here, even from
>>> someone who wrote in C for a living for 30 years. It's not meant to
>>> burn... it's another point of view.
>>
>> The lack of floats problem is a "burning" problem of cc65 IMHO.
>
> not sure about that really.... floats are terribly slow on 8bit platforms, i
> never really missed them at all - there is nothing you cant do without them
> :)

Well.. There is nothing you can't do without a C compiler either ;-)

In fact, generally I agree with you but floats are C standard. And lack of
them is one of the most visible deviations. I'd prefer compiler warning
"this is going to be slow, please consider moving your decimal point and
using ints" ;-) rather than an error message.
--
SD!

Groepaz

unread,
Jun 11, 2013, 6:10:45 PM6/11/13
to
silv...@wfmh.org.pl.remove.it wrote:

> Well.. There is nothing you can't do without a C compiler either ;-)

i have to disagree - for the really obscure bugs and their mind boggling
workarounds.... you really need an ancient k&r compiler =)

> In fact, generally I agree with you but floats are C standard. And lack of
> them is one of the most visible deviations. I'd prefer compiler warning
> "this is going to be slow, please consider moving your decimal point and
> using ints" ;-) rather than an error message.

yeah, they should be there.... maybe some day :) i'd rather try to locate
one or two more optimizer bugs though :)
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!


0 new messages