[Coco] Which version of C?

[K. Pruitt]

Wow, Bill.  Thanks for typing all of that in.  That's a pretty comprehensive 
list.  Thanks a bunch. I'm printing it out now.


----- Original Message ----- 
From: "Bill Pierce via Coco" <coco at maltedmedia.com>
To: <coco at maltedmedia.com>
Sent: Monday, January 12, 2015 5:52 AM
Subject: Re: [Coco] Which version of C?


>
> All of the previous replies to the C version are pretty much "on target", 
> but....
> Those posting the responses (no offence to Gene and Stephen), are not 
> "using" the C compiler, but "remembering" using the C compiler.
> I currently use the OS9 C compiler to compile all my NitrOS9 projects, the 
> current project being "MShell" which is now at about 120+ source files all 
> compiled in one sweep. In setting up my compiler, I found several things 
> that need to be addressed.
> Please keep in mind, this all NitrOS9 L2 oriented. Much of this will not 
> work with OS9 L1 and definitely not Nitros9 L1 which has NO system memory 
> to run programs.
>
> 1.C.Comp over C.Pass1 & C.Pass2... (Coco3 L2 only). Why compile in 2 parts 
> with even more disk activity? If you're using level 1, then C.Pass1 & 
> C.Pass2 are the only choice (good luck with that). I first acquired 
> "C.Comp" from Gene's site and found it would error out on long source 
> lines. I then found a version in the NitrOS9 repo (build but not on any 
> disk, as usual) that does not error on long lines. This is the version I 
> use currently (both have the same version #). I've heard it said the 
> "C.Comp" is just "C.Pass1" & "C.Pass2" combined, but I don't think that is 
> the case. In looking at the C.Comp sources, it looks like it is the C 
> compiler from OSK ported to OS9 6809.
>
> 2. For now, the standard MW C.Prep. The reason I say this is that 
> C.Prep19b has a slight memory problem when it hits long lines in the 
> sources. I have 2 files it will crash on and had to go back to the MW 
> version (no crash), for now. Willard and I have discussed this and may 
> have found the problem, as the original author states in the docs that he 
> reduced the "line buffer" from the standard to save some memory and to 
> increase it as needed. That variable is one of the first listed in the 
> source so we hope that changing that and recompiling will solve the 
> problem. Until then, the MW version is my choice.
>
> 3. CnoY - CnoY is a unique utility and optimizer. I have no idea who wrote 
> it or where it came from. I first heard of it from Mike Knudsen 
> (Ultimuse3) and then found the file on Gene's site. It's a one-trick-pony 
> and all it does is to scan the created asm code from C.comp and change all 
> the "LEAX xx,Y" to "LDX #xx", giving about a 15-20% savings in size and 
> speed of execution. I highly recommend this utility.
>
> 4. Use "RMA" and "RLink" in place of "C.Asm" and "C.Link". These are by 
> far better versions though both by MW. From what I understand (and read), 
> RMA addresses a few issues found with C.ASM and was also designed from the 
> ground up with L2 in mind.
>
> 6. C.Opt - I don't know the version or who wrote it, but there's a "newer" 
> version than the MW version and I use it. I have had no problems yet.
>
> 7. "Make" by Tim Koonce (Make_TK & NewCstart). By far a better "make" than 
> Tandy's and CK's cstart takes advantage of it. TK's make allows more 
> flexibility and cmd line options than the original by Microware.
>
> 8. "clib.l" & "cstart.r" - by Carl Kreider. Definitely a more "complete" C 
> library than Tandy's with a few bug fixes as well. The "cstart.r" fixes a 
> few Tandy bugs and is more efficient (smaller?).
>
> 9. If you are going to use Graphics or MV style menus in your code, then 
> you'll need Mike Sweet's "cgfx7" (cgfx.l) which replaces the Tandy version 
> with MANY more commands and bug fixes to the originals.
>
> 10. "Touch" - Updates the "Last Date Modified" on sources and binaries. I 
> think this was also redone by either TK or CK, not really sure.
>
> 11. Last but not least, RcR. RcR is a front end replacement for CC, CC1, & 
> CC2 and written by Mike Knudsen. As it stands currently, it compiles all 
> temp files to a ram disk (hard coded for /r0) and all RELS to where ever 
> the Link script points. RcR utilizes all of the above utilities and is 
> hard coded for them specifically. But the sources are available (through 
> me) and it can be modified to suit your needs. The really nice thing about 
> RcR is it leaves no trash behind. All temp files are cleaned up and 
> removed.
>
>
> Those are the files I currently use to compile all my projects. I have 
> been using these over the past 4 years and I've honed it down to those 
> utilities. If the line memory fix for "C.Prep19b" works, then that will be 
> added to my arsenal.
> I have sources for "most" of these files and so they can be altered to 
> your own needs. This compiler system is designed from the ground up to 
> compile large numbers of source files from just one makefile under OS9 L2. 
> I have an good example of how to use all the files on my "MJK C Compiler 
> System" website as well as downloads for all the files:
> https://sites.google.com/site/dabarnstudio/mjk-c-compiler
> (I really need to redo this site as I've learned a lot since I started it)
>
> Keep in mind, this is not "what I remember", but "what I use" daily. Both 
> of my "Award Winning" programs(2013 "Last Annual CocoFest" CocoCoding 
> Contest), "Sound Chaser" and "DW4Man" were compiled using this system. It 
> is currently in use on my latest "MShell" project which has over 120+ 
> sources compiled into about 10 or 11 modules. It was also used to compile 
> my latest enhancements to Mike Knudsen's "Ultimuse3" (150+ sources) in 
> which I added several DW4 features including my "Internet Updater: which 
> allows the program to update itself to the latest version from the 
> internet FTP straight from the Coco using DW4.
> So here's the final rundown:
>
> "clib.l" & "cstart.r" - Carl Kreider
> "cgfx.l" (CGFX7) - by Mike Sweet
> "make" Tim Koonce
> "Rcr" - by Mike Knudsen
> "C.Prep" - by MicroWare (Unitl "C.prep19b" gets the memory fixed)
> "C.Comp" - by ??
> "CnoY" - by ??
> "RMA" - MicroWare
> "C.Opt" - by ??
> "RLink" - by MicroWare
> "Touch" - by MicroWare or ??
>
> And if using a real Coco, I suggest a ramdisk to speed things up. Gene's 
> "MyRam" is the absolute best.
> I use this compiler system on the VCC Coco 3 emulator at about 71mhz 
> (overclocked) as that increases compiling speed by about 2000% (not 
> exaggerating either). My MShell project takes about 3-4 hours to compile 
> on a real Coco 3. On Vcc overclocked, it compiles in about 45 seconds.
> So I add Vcc to my compiler list.... or I would be pulling my hair out 
> waiting on the Coco :-)
>
>
>
> Bill Pierce
> "Today is a good day... I woke up" - Ritchie Havens
>
>
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> E-Mail: ooogalapasooo at aol.com