[comp.sys.cbm] C Language for Commodore 64/128

aliu@sal8.usc.edu (Alejandro Liu) (10/02/88)

=========================================================
Hi to all the people in the net!
I was thinking about buying a C Language compiler for the
Commodore 64/128 (I have a 64 but soon I will have a 128)
And I have some questions about it:
      1) Which one is the best one? I have heard
         comments about Super C and Power C.
      2) Are they compatible for  64 and 128  (I
         mean, do I need  a  different  compiler
         for each machine?)
      3) How big is the object file?
      4) Is the object file created by the  pro-
         gram copyrighted?
      5) Is it cheap or Public Domain?
      6) Does it allow portability to  and  from
         other system? Does it have a linker and
         accepts "include" files?
      7) How good is the documentation?
I really need a C compiler, but I wouldn't just jump in-
to the first compiler I see.  The thing that I am  look-
ing for here is a cheap, reliable and portable language.
(No I don't plan to write UNIX for  C-64, I am not  that
smart, yet!)

                    aliu@nunki.usc.edu (Alejandro Liu)
(Simple .signature, $CHEAP$)

                   Alejandro Liu (aliu@girtab.usc.edu)

randy@uokmax.UUCP (Longshot) (10/03/88)

In article <1520@nunki.usc.edu> aliu@nunki.usc.edu (Alejandro Liu) writes:
^=========================================================
^Hi to all the people in the net!
^I was thinking about buying a C Language compiler for the
^Commodore 64/128 (I have a 64 but soon I will have a 128)
^And I have some questions about it:
^      1) Which one is the best one? I have heard
^         comments about Super C and Power C.

Power C is definately what you want.

^      2) Are they compatible for  64 and 128  (I
^         mean, do I need  a  different  compiler
^         for each machine?)

Power C comes with 2 disks-- one for each system. Super C is ~60 dollars for
each system.

^      3) How big is the object file?

A program I wrote to print C files with the special characters on my dot-matrix
was 36 blocks under Super C, and 9 under Power C.

^      4) Is the object file created by the  pro-
^         gram copyrighted?

No in both cases.

^      5) Is it cheap or Public Domain?

Power C was $39.95 last I heard. Updates, anyone?

^      6) Does it allow portability to  and  from
^         other system? Does it have a linker and
^         accepts "include" files?

Within reason, or, so to speak, as portable/compatible with the outside world
as any CBM-related beast.

^      7) How good is the documentation?

Good if you already know C, but don't expect a C tutorial.

^I really need a C compiler, but I wouldn't just jump in-
^to the first compiler I see.  The thing that I am  look-
^ing for here is a cheap, reliable and portable language.
^(No I don't plan to write UNIX for  C-64, I am not  that
^smart, yet!)
^
^                    aliu@nunki.usc.edu (Alejandro Liu)

As I said to begin with, go with Power C. There are several caveats and bugs
that others have found. Maybe someone will post an updated list. I could use
such a list myself.

Randy
-- 
Randy J. Ray			       University of Oklahoma, Norman, Oklahoma
randy@uokmax.uucp			Ignore what I say. OU does...
RJRAY@aardvark.ucs.uoknor.edu
-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-=*-

rickc@pogo.GPID.TEK.COM (Rick Clements) (10/04/88)

I own both the Super C and Power C compilers.  The following are my opion
and I don't work for either company (disclamer):

I think Power C is a better buy.  But, both compilers have their own
advantages.  The follow list is a summary:

    Power C                             Super C
    ------------------------------      ---------------------------------
    + The disks aren't copy protected   + Documentation is much better
    + Native code (smaller, faster      + Supports more data types (longs &
      binaries)                           doubles)
    + Half the cost                     + Graphics library
    + C64 & C128 compilers together     + RAM disk better supported
    + Source format supported by Kermit + Better availability
    + Both C64 & C128 will optionally   + C64 will optionally run as a BASIC
      run as a BASIC program              program.  C128 will auto boot.

Which compiler has a better programming environment (editor ect.) is a matter
of taste, I like Power-C's better.  Except for the RAM disk, Super-C has a
single RAM disk that will expand as extra memory is added.   Power-C has
48K which is chopped in half.

The Power-C disks aren't copy protected.  You can back them up.  If you have
spent weeks getting a large program running only to have your [spouse |
children | dog | equiptment failure] trash you disk ....

The documentation for Super-C is much better.  There is a C turtorial and a
description of the tools.  Power-C gives you more of a quick reference guide.

Power-C is about half the cost (about $30).  For this cost you get a C64 and
a C128 compiler.  With Super-C you one or the other.  I think Super-C is about
$60, but I had it longer.  Either price is very good for a compiler.  I have
worked for companies that have spent more on compilers that didn't work any
better (or as well in one case).

Super-C supports more data formats.  If you need the extra percision of
long int's for double's, your choice is simple.

Kermit supports the source format for Power-C.  If you want to port things
from the net, this is a big plus.

Super-C supports a fair graphics library.  You select a color pallete of
four colors.  It allows you t place figure is the forground or background.
You can also save and restore boxes.  Nice for menu's.

Power-C generates native code.  Super-C generates "P" code.  It is an inter-
medate language that is interpeted.  This slower and usually longer binaries.

The availablity (localy) is better for Super-C.  Several stores carry it.
No one carries the Power-C localy.  It took several calls by the store before
they could find a distributor that carried it.  (They carry other packages
by Spinnaker.)

Both compilers are fairly good.  Neither are perfect.  Super-C choked on too
many strings and produce an "exception error" (description: this error
shouldn't occur).  Power-C kept giving me syntax errors following the end
of my program (problem: blanks after the ending "}").  Both will run into
small system problems (too many string constants, large source files will
need to be split, ect...).

Both do a good job of supporting K&R C.  Neither support the ANSI extentions.
Both have fairly standard libraries (for current versions of the compilers).

BTW, if you port programs, you will quickly notice a difference in stream
declarations.  On most systems you will declare "FILE *stream_ptr;".  With
both Super-C and Power-C you declare "FILE stream".  This is because the
file system is handled by the disk and not the system CPU.

If you are just learning C, Super-C might be better because of the better
documentation.  If you are going to port code, Power-C is supported by
Kermit.  If I had to choose just one, I would pick Power-C; its not copy
protected and it costs less.

-- 
Rick Clements (RickC@pogo.GPID.TEK.COM)

mclek@dcatla.UUCP (Larry E. Kollar) (10/04/88)

In article <1520@nunki.usc.edu> aliu@nunki.usc.edu (Alejandro Liu) writes:
>I was thinking about buying a C Language compiler for the
>Commodore 64/128 (I have a 64 but soon I will have a 128)
>And I have some questions about it:

This is a question that comes up often.  While most people will say, "Go with
Power-C," I'll try to present a balanced comparison.

I have both Super-C and Power-C on my 128.  While I've been using Power-C almost
exclusively in the last year, each has its own set of strengths and weaknesses.

Power-C --

	Strengths:
		Not copy-protected!!!
		Cheaper (about $39, includes both 64 and 128 versions)
		Faster compiling
		Smaller object code
		Faster object code
		Public-domain assembler available
		Can generate standalone code

	Weaknesses:
		User interface doesn't support RAM expansion cartridges
		Only 16-bit integers, standard BASIC-style floating point
		Doesn't handle initializing arrays of structs too well
		Documentation is poor, to offer an understatement

Super-C --

	Strengths:
		Supports 32-bit long integers, double-precision floating point
		Documentation is more complete
		Supports RAM expansion cartridges (including 512K cartridge)
		Editor supports color in source (nice for comment blocks & such)

	Weaknesses:
		Copy-protected - couldn't copy even with Copy II 64/128
		"Standalone" programs only with (distributable) Super-C shell
		Slower all around
		Non-SEQ file format (tradeoff:  you want color?)
		More expensive than Power-C (about $60-$70)
		You have to buy separate versions for 64 and 128

Basically, it depends on what you need.  If you're working with higher-precision
numbers, Super-C has no competition.  If you're trying to learn C itself,
Super-C is easier to work with because of decent documentation & some tutorial
information.  There is a little technical support for Super-C, including a
utilities disk (call Abacus).  Avoid Version 1 like the plague!!!

Most (all?) of the Usenet people prefer Power-C, which means you have a pretty
good informal support line right here.  If you're writing programs you want to
distribute, Power-C is the way to go.  If you want to mix C and assembler,
Power-C is the only way.  I heard there is (was?) a BBS for Power-C, run by
Pro-Line (the original authors).  Don't forget the assembler and other
public-domain utilities, written by Mark Rinfret (many thanks, Mark!).

Hope this helps,

	Larry Kollar	...!gatech!dcatla!mclek
	"It's easier to try, than to prove it can't be done,
	 And it's easier to stay, than to turn around and run."

bphollander@watcgl.waterloo.edu (Brian Hollander) (10/04/88)

About the two C compilers, Super C and Power C, I would like to ask about
size of object files and execution speed.  It is my understanding that
Super C is an interpeted C which includes all the libraries every time
you link.  This would produce compact code plus a constant amount
from the libraries.  Power C produces machine code (much larger) but
links only parts of the libraries that are used.  The difference in
speed should make Power C much faster than Super C.

Since I'm a user of Power C only, could someone post some specific
info on the differences in code generation and runtime execution
of the two compilers.

As for the long awaited bug list this is my contribution to the list.

Power C places the first 32 bytes of local variables in zero page memory.
When a new function is invoked it clears out however many bytes of
zero page it needs by pushing the old stuff to the C stack, not the CPU
stack.  If you pass the address of a zero page stored variable to one
of YOUR functions (library routines do not clear out that part of zero
page) and that function uses enough zero page variables to push the 
old one to the stack, then the address is no longer valid.  It still
points to the zero page address where it used to be.

This example should demonstrate the problem.

main()
{
  int value;

  value = 5;
  foo(&value);
  printf("value = %d\n",value);
}

foo(value)
int *value;
{
  int var1,var2,var3; /* a bunch of locals only one is needed here */

  *value = 20;
}

When this is run value should be 20 but it will be 5.

I have not tested this specific example but others that are similar.  This
means that this example will work fine on someone else's computer because:
1 - They are using a version where this bug has been fixed.
2 - My C64 was having a bad day (occurs very often)
3 - I'm seeing things.

My system is: A C64 (OLD one), 1541 Tape (I mean disk) drive (older than the
C64), 1764 RAM expansion, 1541 Express (holding the disk together) and
the 1581 DISK DRIVE.  I'm using Spinnaker's version of Power C (C Power)
with a self modified shell to use the RAM expansion as a third drive.


It is possible that this bug does not appear on the 128.



I have also noted that there are two useful function not documented:

kernel(0 or 1) - banks kernel out or in. (useful to have in).
device(device number) - sets default device for fopen, ferror...
                        good to know if you have more than 1 drive.




If anyone else comes across useful information (undocumented functions,
hard to find bugs) PLEASE post it to the net.  It may save me some long
sleepless nights!




        Brian.



-- 
uucp    :  ...!watmath!watcgl!bphollander
internet:  bphollander@watcgl.waterloo.edu

mat@emcard.UUCP (Mat Waites) (10/04/88)

In article <6135@watcgl.waterloo.edu> bphollander@watcgl.waterloo.edu (Brian Hollander) writes:
}
}I have also noted that there are two useful function not documented:
}
}kernel(0 or 1) - banks kernel out or in. (useful to have in).
}...
}        Brian.

Also useful to have out if you have copied the ROM to RAM and have tweaked
it here and there.

Mat


-- 
 W Mat Waites            | Emory Cardiac Data Bank | UUCP:  gatech!emcard!mat
                         | Atlanta, GA             | PHONE: (404) 727-7197

******** End of newsgroups--what next? [npq]

bulkow@rt2.cs.wisc.edu (David Bulkow) (10/05/88)

In article <6135@watcgl.waterloo.edu> bphollander@watcgl.waterloo.edu (Brian Hollander) writes:
>
>....................  I'm using Spinnaker's version of Power C (C Power)
>with a self modified shell to use the RAM expansion as a third drive.

I wonder if anyone could explain the modifications necessary to make the 
RAM expansion visible to the shell in Power C.  It would be nice to be
able to use the expansion, particularly during program develpment.  Disk
drives tend to be slow.

Dave Bulkow

emjay@dasys1.UUCP (Michael J. Lavery) (10/05/88)

In article <1810@puff.cs.wisc.edu> bulkow@rt2.cs.wisc.edu (David Bulkow) writes:
>
>I wonder if anyone could explain the modifications necessary to make the 
>RAM expansion visible to the shell in Power C. 

	For notes on Power C and the REU see the article:

Adrian Pepper, "On the C Side", TRANSACTOR, July 1988, Vol. 9, Issue1,
    pp 54-55.

	The TRANSACTOR has published articles on Power C in the last two
or three issues.


-- 
Michael J. Lavery
Big Electric Cat Public UNIX
..!cmcl2!phri!dasys1!emjay

ross@ziebmef.uucp (Ross Ridge) (10/08/88)

In article <6135@watcgl.waterloo.edu> bphollander@watcgl.waterloo.edu (Brian Hollander) writes:

>When a new function is invoked it clears out however many bytes of
>zero page it needs by pushing the old stuff to the C stack, not the CPU
>stack.  If you pass the address of a zero page stored variable to one
>of YOUR functions (library routines do not clear out that part of zero
>page) and that function uses enough zero page variables to push the 
>old one to the stack, then the address is no longer valid.  It still
>points to the zero page address where it used to be.
>
>This example should demonstrate the problem.
>
>main()
>{
>  int value;
>
>  value = 5;
>  foo(&value);
>  printf("value = %d\n",value);
>}
>
>foo(value)
>int *value;
>{
>  int var1,var2,var3; /* a bunch of locals only one is needed here */
>
>  *value = 20;
>}
>
>When this is run value should be 20 but it will be 5.
>
>I have not tested this specific example but others that are similar.  This
>means that this example will work fine on someone else's computer because:
>1 - They are using a version where this bug has been fixed.
>2 - My C64 was having a bad day (occurs very often)
>3 - I'm seeing things.

This realy isn't so much a bug as an undocumentated feature. C Power (all
versions) has in effect a new storage class (which I like to call) "zero-page".
By default the first 32 bytes of (what would be automatic) variables
in a function have this class. "Zero-page" storage-class is sort of
cross between register and automatic storage classes. If you think of these
varibles this way, you can go along way in avoiding problems

>If anyone else comes across useful information (undocumented functions,
>hard to find bugs) PLEASE post it to the net.  It may save me some long
>sleepless nights!

Two solutions to the above problem:

       Declare the varible explicitly as automatic (ie. auto int a;)
       Compile with "cc -a file.c"


[ Ignore the below signature, mail any replies to:
     ross@watcsc
     !watmath!watcsc!ross ]
-- 
 l/                   uunet!attcan!lsuc!ncrcan!ziebmef!ross              //
[OO]                   or just call me Ross for short...                [oo]
-()-                                                                    -()-
 db                     6502 assembly forever!                           //