[Color Computer] [coco] Learning MW C

[Gene Heskett]

On Saturday 12 August 2006 11:23, Joel Ewy wrote:
>Carey Eugene wrote:
>> From: "George's Coco Address" <yahoo at dvdplayersonly.com>
>>
>>> For several years, I've been wanting to learn "C" .. the one that
>>> comes with OS-9.
>>>
>>> The hang up is peeks and pokes. I can't find a way to do this with
>>> "C".
>>
>> The other replies have already told you how to do the equivalent of
>> peek & poke, however I have just got to add a few things.
>>
>> First, I'm not so sure it's a good idea to learn that old MW C.  It's a
>> limited form of K&R style C.  It doesn't meet the current 1999 ISO C
>> standards, or the 1989 C standards.  It doesn't even completely meet
>> the old K&R unofficial C standards.  It has some limitations and quirks
>> due to it being an 8 bit compiler.
>
>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
>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.

And don't forget that we do have addition preprocessors that can be 
incorporated into the MW compilers various cc commands, which will for the 
most part convert ansi code into something the rest of the compiler 
understands just fine.

I'm thinking of ansifront-0.12, which is inserted into the execution 
sequence, treating the c.prep output and correcting to K&R style, all 
those references to void into int's.

All told we have quite a few improvements to that MW C that generally do a 
pretty good job of glossing over the diffs.

Start this whole tuneup by replacing the MW c.prep with the my edition 19 
version of it, swatting many bugs that show up when the src files exceed 
about 12k, it remains able to build good output when the srcs exceed 32k 
as shown by its ability to build rzsz.

Then plug ansifront-0.12 as next in the sequence.

Then after c.comp2 (or c.comp for those that have it) and c.opt, there is 
c.opt2 and CnoY, both of which do further optimizations and then the 
assembler can be replaced with one that understands the 6309 assembly code 
in case you want to '6309'ize the output of the above, which can offer 
some further speedups in the final object generated.  Thats relatively 
easy to do if you speak assembly reasonably well.

Then there are replacement c.libs, starting with the obligatory Krieder 
version (its almost mandatory), and a trig.l for the higher math 
functions, and no doubt there are other library additions that can be 
called on by the linker c.link.

With all of the above in place, the compile times are slowed down some, but
I've found very little code out there that was written prior to the advent 
of Ansi-C (and which could do anything usefull for the coco of course) 
that would not compile as is and run just fine on a 2 meg, 6309'ed  coco3.

>> Microware's C compiler was the first version of C that I learned, and
>> when I later switched to a more modern compiler, I had a lot to unlearn
>> and re-learn.
>>
>> Now, having said that, if you want to learn it and use it, go ahead....
>>
>> But, unless you are planning on doing something rather unusual, like
>> accessing hardware directly, you shouldn't really need 'peek' and
>> 'poke'.
>>
>> C can do that sort of thing, and about anything else.  But C prefers
>> that you deal with more abstract data types.  Arrays, structures,
>> pointers to them, etc.
>>
>> Never directly 'peek' and 'poke'ing data.  You can do it.  But you
>> rarely will need to do it.  If you do, then you are probably doing
>> something 'wrong'.  (Like writing ASM style code in BASIC, Fortran,
>> PASCAL or C... You can do it, but it'll look ugly, be awkward and wont
>> take advantage of the features and abilities of the language.)
>
>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'd suggest you browse the web for a few good free C tutorials.  (Just
>> be aware that whatever you find will likely be for ANSI / ISO C, rather
>> than the older K&R C.  If you browse hard enough or search the p2p
>> networks, you might be able to find a scanned copy of the Kernighan &
>> Ritchie's original K&R C book.)
>>
>> ...
>
>What alternatives are there for C programmers on the CoCo?  I know of
>James Dessart's GCC cross-compiler, which now seems to be maintained by
>someone else at this site:  http://www.oddchange.com/gcc6809/.  How well
>does this work with the CoCo?  With OS-9?  It looks like you need to add
>linker, assembler, etc. to get a complete toolchain.  And it looks like
>there are few if any libraries that will work with this thing on the
>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.
>
>JCE

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.