[Coco] C Programming
gene.heskett at verizon.net
Sat Feb 6 20:32:02 EST 2010
On Saturday 06 February 2010, Stephen H. Fischer wrote:
>Yes but we have a preprocessor (Front End?) that does much of the
>conversion. But not all.
>Anyone using "C" should make a substitution of a better set of tools.
>Perhaps someone has a list of then, I remember a post years ago.
>Maybe from Gene.
1. Ansifront-0.12 is a given. It converts a huge percentage of ansi-c src
code into something digestible by the rest of the compiler.
2. My cprep19 is another unless your srcs never go over 8 or 9k.
Basicly, if your code compiles but crashes, use my cprep, its been tested
with sources to nearly 40k.
3 cc drivers, including our old 'make' or any of the scripts are up to the
user. All can do the job if run correctly.
4. cc1->cc2 can be used, or there are copies of cc itself about, usable only
an a coco3 with more memory. No particular speed advantage to the one piece
version if using a ramdisk for scratchpad. Results at the output are
identical. Assembly code, code that may just show you a trick or 2 if just
learning assembly. Its also a good place to stop the build, plug in your own
tricks, and then continue with the assembly and linking.
5 there is an extra c.opt2 about that can help a wee bit.
6. There is, only for coco3, a "CnoY" utility that removes y register use as
its a cycle longer to use, a minor speedup in the object.
7. There must now be at least 3 or 4 versions of its 'rma', relocating macro
assembler, and I believe matching versions of r.link, which takes the
assembled code, and links in the library routines to make a complete,
standalone executable binary. The idea between 4 and here, is that if you do
come massaging of the assembly code to optimize it better for the h6309, then
you will also need the later versions of rma that understand 6309 nemonics,
and I believe for the linker used.
8. The std clib.l (??name) should probably be replaced with Karl Kreiders
version, more accurate, and more optimized.
9. For trig usage, there is the trig.l that was built from code published,
somewhat sloppily IMO, in the rainbow long ago. I had a heck of a time
telling the diffs between the character one '1', and the letter el 'l' as
shown by the font and dmp printer output used to make the plates that printed
the rainbow. It only works right when you get it right. And gives answers
accurate to 1.0ee+-16 or 17 digits, that is a few digits more accurate than
the other languages we have.
There is probably more, but that is a general outline.
>----- Original Message -----
>From: "Dave Kelly" <daveekelly1 at embarqmail.com>
>To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
>Sent: Saturday, February 06, 2010 3:40 PM
>Subject: Re: [Coco] C Programming
>> Willard Goosey wrote:
>>> Old Testament: _ by Brian W. Kernighan
>>> and Dennis M. Ritchie, First Edition. This is exactly (except for a
>>> few ommisions and bugs) the language the compiler supports.
>>> It's out of print, so look for it used.
>>> Also: The manual for the C compiler itself, and the docs for all the
>>> replacement programs and libraries for it.
>> There are 2 versions of "The C Programming Language". One is ANSI 'C' and
>> the older version is not.
>> OS9 is the other, pre-ANSI 'C', first edition.
>> function_name ( int variabel, char *varable ) produces an error.
>> function_name ( )
>> int variabel;
>> char *varable; does not.
>Coco mailing list
>Coco at maltedmedia.com
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
I disagree with unanimity.
More information about the Coco