[Coco] Coco OS9 Source Control (question)

Bill Pierce ooogalapasooo at aol.com
Mon Jun 16 22:46:21 EDT 2014


Gene, Greg and Chris, thanks :-)
Every reference I find, says to seed the intitial CRC values with $FFFFFF also. I guess this is to make the first iterration turn 00s (??)
 
The only real problem I have with using a CRC value, is that each file would have to have to be loaded and calculated then compared to the checksum record then copied to the archive before each compile. This would take a lot of time on a complete compile of a large multi-source project. One caveat, is that the compiler only loads and compiles the files that have changed since the last compile, so only those files need the crc check on that round.

Since I use VCC with overclocked CPU (about 72mhz) for all my developement, the extra time will not really be noticed as I can compile a 50-60 file project in less than one minute (sometimes less than 30 sec), but on a real Coco with a large multi-source project (almost all of mine are), it could take hours (it already does).

But the savings in time for trying to recover from a batch of bad edits when I forgot to backup the sources would make it all worth it "-)

I will look into this and weigh the otpions against the "last modified" date idea... I know CRC would always be more accurate, but time and program space would also be considerd. Memory is no problem. I can load 8k chunks into the G/P buffers already in place in the GUI and have direct access to 8k at once. Matter of fact, my buffers are dynamic, so I can load the complete file into a series of buffers, do the CRC check, then kill the buffers. Probably the largest source I deal with is about 24-28k (worst case senario), so the 8k chunks would not be bad. 3-4 passes at the most. The average size is about 8-12k.

The custom "front-end" (rcr) I use for my compiler is easy to modify (I have the sources) and adding the source control would be easy... Hmmmm... Maybe a new C compiler system is a comin :-)
Curently, my compiler system consists of:

Make_TK - a much more robust version of make than the MW version and without the bugs. (by Tim Koonce)

Rcr - replacement for C1, C2, and CC, faciliates the use of "c.comp", "make_tk", and a ramdisk  (by Mike Knudsen)

C.prep19b (by Willard Goosey)

C.comp - not as many bugs as c.pass1 & c.pass2 (ported from OSK or Unix??)

CnoY - massages the "LEAx offset,y" to "LDx #offset" and "op offset,y" to "op offset" or "op >offset" in the asm file produced by c.comp to produce smaller, faster code.

C.opt (also improved, but do not know who the author was)

RMA (OS9 Developers package)

Touch (custom version by Mike Knudsen)

RLink (OS9 Developers package)

I really like this compiler system setup. It's clean, stable and doesn't leave a bunch of temp files behind (rcr cleans it all up as it goes). I've used it for almost 4 years now and the only real difference from the MW compiler (other than less bugs) is how the makefile is setup. I can configure the makefile to compile over 150 sources into 25 different modules using C, RMA, and Asm sources all in one pass. I actually have a project that does this. The makefiles used with make_TK make much more sense than the ones used with the MW make. They are organized a lot like the nos9 repo makefiles.

Thanks again guys... I'll let ya know if I get it all to work :-)
 

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-Webmaster of The TRS-80 Color Computer Archive
http://www.colorcomputerarchive.com/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
E-Mail: ooogalapasooo at aol.com


 


More information about the Coco mailing list