[Coco] Which version of C?

Mon Jan 12 10:56:52 EST 2015

On Monday, January 12, 2015 08:52:27 AM Bill Pierce via Coco did opine
And Gene did reply:
> 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

And I will flat out state the Bills experience is newer than mine, but I 
have resisted the vcc route even if I do have the machinery to run it. 
Bill is one of the people "doing it" for us right now, and gets an 
obvious tip of the hat from me for doing something.  Whats not to love? 
:) 
> 
> 
> 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


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS