New C compiler for the 128?

[xlar54]

Hey guys,

There has been some interest here on Super C and Power C. Im curious, for the developers out there, if writing a new C compiler for the 128 might be an interesting project? I am a coder at heart, but admittedly, Ive never written a compiler. Written a number of interpreters, but no compilers. C *seems* to me to be a much easier language to write a compiler for, especially with all the free C compilers (with source) that are out there.  Thoughts?

[xlar54]

I was poking around, looking for what would be considered the smallest C implementation.  I ran across this:

http://www.cpm.z80.de/small_c.html

Seeing as we only have so much room to work in, I figure that it makes sense to look for a small implementation to maybe port from. But I dont think this is exactly what is needed just yet.  The search continues...

[StyleCHM]

Whats wrong with cc65 then?

[hannenz]

Whats wrong with cc65 then?

it doesn't run on a commodore
cc65 is great but i prefer the real machine to code on.
That's an interesting question in fact, designing a new Compiler, i did think about that too. On the other hand, we have Power-C, and I don't think that there is much sense in improving it, since it IS GOOD software. There are a few awkwards of course, but you can come along quite giid with Power-C, sometimes I even make a fast imlpementation with gcc on my linux machine and have never had problems porting it to Power-C if you keep to K&R from right the start (which gcc does still understand ).
I don't think that one could get a C-Compiler faster/ smaller/ better/ than Power-C is. You could make it more ANSI compatible, yes, but I don't know if that will be worth the trouble. And as i have proven, improving the (std) libraries of Power-C is doable quite easy and makes more sense in my eyes than a whole new compiler. Maybe someone could rewrite the Power-C's shell to support more modern devices, such as MMC2IEC for example...
On the other hand, i like the idea of designing a compiler. I have written assemblers and interpreters before but never a compiler; if there will be a project on a new Compiler i'll sure be in it, simply for the fun and experience of doing such a thing.

[StyleCHM]

cc65 is great but i prefer the real machine to code on.

eeeek! Once i found cross-compiling/assembling, I could never go back

hats off to you!

[xlar54]

Yeah, absolutely nothing wrong with CC65. This would be more an exercise in developing a compiler native to the 128, as well as of course tinkering more with assembly.  For me, Im always impressed when I see a project begin to take life from scratch, especially when it comes from ordinary folks instead of software companies.  Speedscript was an amazing piece of work and competed against big name word processors of the day. And the principals learned during development would be transferable to other platforms as well, I would imagine.  Honestly, there's not much of a practical point to doing any development for the 128 these days, but it's still enjoyable.  Game development is the only area I could never get into...not because it was hard, but because I just wasnt a gamer - and I tend to have ADHD when it comes to finishing projects.

Anyway, more feedback is requested.  If there's enough support, this might could turn into something.

[redrumloa]

Anyway, more feedback is requested.  If there's enough support, this might could turn into something.

I'm a complete novice, but I would be interested as a user.

[BigDumbDinosaur]

I'm not a heavy user of C in eight bit endeavors, so my interest would be more academic than any thing else.  Your biggest challenge would be in implementing a reliable math package and bit fields.  I/O libraries would also be interesting, although there's plenty of prior art at which to look.

Frankly, I doubt you could develop anything better than Power C or the 2500AD 6502 compiler, both of which were excellent examples.  However, don't let that discourage you.  The knowledge you would gain would greatly enhance your M/L coding skills.  Just be sure to write a very clean and well-commented source code, because you will probably spend a fair amount of time debugging your compiler before you are truly satisfied with it.  The ultimate test will be if you can get 100 percent ANSI-compliant code to run through it okay and produce a clean and compact 6502 object output.

[xlar54]

Thanks BDD.  I actually thought about writing the compiler *using* CC65.  Would speed development, and it would be easier to translate source from other ...sources, since C compiler sources are out there.  Hmm... and maybe that editor Im working on would make a decent editor for it as well.

[hannenz]

i totally agree with BDD that improving Power-C is quite impossible. there are some features missing there, wchih one could possibly add, but then it would be easier to hack Power-C instead of rewriting from scratch. missing features are:

- bit fields
- long
- signed chars
- typedef struct { /*...*/} newtype; doesn't work... needs to first define the struct then typedef'ing it in a seperate instruction.
- well, the K&R syntax of course should be changed to ANSI-C
- (real) prototypes
- string constants concatenation
- const modifier
- some handy preprocessor directoves

[if just someone had the sources for Power-C --- no chance that somebody happens to have a copy of it??]

i can't think of any more features i ever missed in Power-C. that's true...
and for the libraries: hey. you can implement whatever you like, that's in fact the cool thing aboutthat whole business. just look at my pages what i did, concerning libraries...

far more attractive it would be to replace the whole "os" (shell) it's running on. having a more sophisticated file system, maybe even multitasking (we're on c128, there were several attempts on multi tasking environments, afaik, so it *could* be possible...) but that's another story... though that would be very interestnig and educational, too


for resulting performance of the new compiler, i don't think that using cc65 is a good idea, since you only can get a reasonable fast compiler if it is done in ml, at least most of the time-consuming routines. You could use a C-"frame" for handling input/ output files and the like but i think the actual compiling job must be done in ml. no other way, i think. (not that cc65 would generate bad or slow code, but it can't compete with hand-written optimized ml).

hey, but how about throwing the cc65's source code at Power-C...heh??!

[BigDumbDinosaur]

i totally agree with BDD that improving Power-C is quite impossible. there are some features missing there, wchih one could possibly add, but then it would be easier to hack Power-C instead of rewriting from scratch. missing features are:

- bit fields
- long
- signed chars
- typedef struct { /*...*/} newtype; doesn't work... needs to first define the struct then typedef'ing it in a seperate instruction.
- well, the K&R syntax of course should be changed to ANSI-C
- (real) prototypes
- string constants concatenation
- const modifier
- some handy preprocessor directoves...

A lot of the missing features in Power C more reflect the limitations of the environment than the skills of the original author.  Some of that stuff gets hairy in an eight bit system, especially longs, which are 64 bit numbers.  Math routines to do FP 64 bit arithmetic on the 6502 tend to be unwieldy and slow, not too mention inaccurate due to ASCII to binary conversion errors.  BCD is better in that regard, but even slower.

Frankly, I've never considered C a good fit with any Commodore 8 bit machine and didn't even look at it back in the day.  The required resources to create a fast and pleasant development environment really aren't there, and in any case, C is only a few steps above assembly language.  M/L is a whole lot faster in terms of execution speed and compactness of code, and if you have a large library of tested and documented subroutines as I do, development is not nearly as tough as scratch-writing everything.  Of course, C is less daunting for higher level work...FOR loops are much easier to contruct, eh?

[hannenz]

A lot of the missing features in Power C more reflect the limitations of the environment than the skills of the original author.  Some of that stuff gets hairy in an eight bit system, especially longs, which are 64 bit numbers.  Math routines to do FP 64 bit arithmetic on the 6502 tend to be unwieldy and slow, not too mention inaccurate due to ASCII to binary conversion errors.  BCD is better in that regard, but even slower.

yes, but i've run into several situations were i at least would have needed 32bit "longs" (the Power-C"'s int type is 16-bit, so we should better say: 32-bit-ints). i wordked around using floats in that situation, which is slow as hell, too

Frankly, I've never considered C a good fit with any Commodore 8 bit machine and didn't even look at it back in the day.  The required resources to create a fast and pleasant development environment really aren't there, and in any case, C is only a few steps above assembly language.  M/L is a whole lot faster in terms of execution speed and compactness of code, and if you have a large library of tested and documented subroutines as I do, development is not nearly as tough as scratch-writing everything.  Of course, C is less daunting for higher level work...FOR loops are much easier to contruct, eh?

i totally agree with you.
nevertheless i somehow fell in love with C, since it is a really elegant, simple but yet flexible and powerful way of writing code. i do a lot in ML too, though, for the same reasons you just pointed out. Power-C lets you mix ML and C quite elegantly, which is, I think, a very nice playground for just about everything: do the tricky stuff in ML or write your custom libs, then glue it together with some C-code.

[BigDumbDinosaur]

Frankly, I've never considered C a good fit with any Commodore 8 bit machine and didn't even look at it back in the day.  The required resources to create a fast and pleasant development environment really aren't there, and in any case, C is only a few steps above assembly language.  M/L is a whole lot faster in terms of execution speed and compactness of code, and if you have a large library of tested and documented subroutines as I do, development is not nearly as tough as scratch-writing everything.  Of course, C is less daunting for higher level work...FOR loops are much easier to contruct, eh?

i totally agree with you.
nevertheless i somehow fell in love with C, since it is a really elegant, simple but yet flexible and powerful way of writing code. i do a lot in ML too, though, for the same reasons you just pointed out. Power-C lets you mix ML and C quite elegantly, which is, I think, a very nice playground for just about everything: do the tricky stuff in ML or write your custom libs, then glue it together with some C-code.

Don't get me wrong.  I do a lot of C in Linux and UNIX.  I just can't see it (no pun intended) on eight bit hardware.  Pointer arithmetic is okay, of course, since integer stuff ion the 6502 is reasonably fast.  FP is another matter.  Dog-slow.

[redrumloa]

Don't get me wrong.  I do a lot of C in Linux and UNIX.  I just can't see it (no pun intended) on eight bit hardware.  Pointer arithmetic is okay, of course, since integer stuff ion the 6502 is reasonably fast.  FP is another matter.  Dog-slow.

Think SuperCPU and the untapped possibilities. I hope any new C complier will support SCPU.