[Color Computer] [coco] Learning MW C

[Carey Eugene]

From: "Joel Ewy" <jcewy at swbell.net>

> Carey Eugene wrote:

>> First, I'm not so sure it's a good idea to learn that old MW C.  It's a
>>
> This is true, though if you really just plan on writing programs for the
> CoCo, standards compliance is probably a non-issue.  If you want to
> learn C for more general use, or with an eye to porting your programs
> between platforms, then it becomes more important.  But Going from K&R
> to ANSI is probably easier than the other way around I would think.  My

Mmmm.... I'm not so sure about that.

The really isn't all that many significant differences between ISO 89/99 and 
K&R.  In other words, you can write almost K&R with C99 if you want. 
Provided you know what you are doing....

So going back to K&R can be done fairly easily, provided you aren't using 
too many C89/C99 features.  Of course, that's the catch.  You have to know 
what you are doing.  What to avoid, what to change, etc.

To me, though, the big benefit of learning C89/C99 instead of K&R are things 
like the function prototyping.  Most of the rest can be ignored as long as 
you are aware of the differences.

I went from Pascal, with strong typing, to K&R C with no typing or function 
prototypes.  It was real easy to screw up parameters and all sorts of stuff.

If you are learning, then I think it'd be better to learn a version with 
function prototypes and a little bit better type checking.


> understanding is that the Microware C compiler does produce pretty good
> code for the 6809, and if that's your intent, I would think it would
> still be a reasonable option.

Not too bad, all things considered.

But I do remember back when I was using it, thinking just how dumb the thing 
was.  Looking at the source code and comparing what I wrote to the asm 
generated often showed a lot of extra useless instructions.  You often had 
to rewrite the source to something the compiler was more comfortable with.

Of course, the compiler had limited space to do optimizations, so you can't 
expect too much from it.

Over all, it did a decent job, but I wouldn't say it was great.



> Right.  The only reason you would need to write directly to specific
> memory locations is if you are writing a device driver -- which should
> probably be done in assembly language on the 6809.  But I suppose that
> it wouldn't be totally wrong to poke at the hardware a little from
> within a C program while figuring out how to use the hardware as you're
> developing your driver.

I never wrote device drivers or anything like that.

The closest I ever came was porting Jean Labrosse's (sp?) minimal uCOS real 
time operating system that he published in Embedded Systems Programming.

I got it running as a task under OS9.  A real time OS running within a 
semi-real time OS.

I had to write a little bit of code to hook into the timer tick and reset 
the latch.  That meant putting my code into the upper 256 bytes of nonpaged 
memory and intercepting the timer and then passing it on to os9.

I never really did anything with it, but it was fun to play with.


> What alternatives are there for C programmers on the CoCo?  I know of

I have no idea.  I'm not involved with the CoCo anymore.  I should have 
already unsubscribed, actually.

There is GCC, Small-C, Forth, etc. but I doubt most of them are truely 
useful and friendly.

And there are a few generic 6809 compilers and such.  But I don't know if 
they'd generate os9 friendly code.


> CoCo.  Am I wrong?  It would be really cool to see this project become
> completely useful for producing CoCo software, but from the look of the
> web sites it would seem that at this moment the Microware C compiler is
> still probably the most usable option for programming in C on the CoCo.

Possibly.  In which case if you are learning C, you are probably better of 
with an old Dos C compiler with a simple IDE.  A more user friendly 
environment for learning.