[Coco] 16/32 bit 6809 derivative

[Bill Pierce]

Gene, in my attempted use of the "newer" C compiler components, c-prep for one is broken. I say this because starting with the initial modification up to Willard's last addition, the buffers for "line length" & "DEF_NODES" were reduced tremendously to make room for new code, therefore reducing the amount of variables as well as code line length. None of the c.prep14, 14a, 14b, or 14c will compile MShell (or Ultimuse3), because of running out of memory or lines too long. I ended up using the Tandy/Microware c.prep as it "just works". I did like the better syntax checking and features, but the memory errors drove me away.

The only mod I've seen for RMA was to make it 6309 compatible, which when used with the C compiler, is useless, unless the C compiler itself is upgraded to generate 6309 asm code (unless there were bug fixes for the 6809 mode).

I'm not aware of any mods to rlink, though I do seem to remember a "TK" (Tim Koonce) or "CK" (Carl Kreider) version floating around.

I do use the "c.comp" over "cpass1" & "cpass2", but NOT the one from your site as it seems to run out of memory (probably same reasons as c.prep). I use the version generated by the NitrOS9 repo (no real source, just an FCB build). It does not run out of memory on me.

I did find a newer c.opt, but no documentation of what was done to it.

I also use a Mike Knudsen custom utility called "CNoY" which when used in the compiler chain, changes "leaX n,u" references to "ldX #n" (X=x & y), which saves a cycle or two as well as making the code smaller (and faster).

I do not use any of the "CC" frontend variants, I instead use a custom frontend, also by Mike Knudsen called "rcr", which allows use of rma, rlink, CNoY, and c.comp and uses a ram disk for temps. It also does a much better cleanup after it's done. I also have the source so I can modify it to suit my needs.

There were sources for all the "new" stuff on Willard Goosey's old site, but when I tried to compile them, they seemed to be written for some other compiler (68k?) and had to be heavily modified to compile with the OS9 C compiler (any variant). When I did get them to compile, very few components worked, and the ones that did, exhibited the above problems.

I tried all the C compiler components from your site and ran into all the problems above. They would probably work fine for small sources or even large sources with fewer variables or labels, but fail miserably on extensive, multi-sources such as Ultimuse3 and MShell.

My compiler chain is:
rcr(MJK) c.prep(Tandy) c.comp(??) CNoY(MJK) c.opt(Tandy) rma(Tandy) touch(CK), then rlink(Tandy).

I also use the Kreider C libraries and Mike Sweet's "CGFX7" as well as a couple of custom libraries that I have put together.

For my use, it "just works" :-)

 

 

Bill Pierce
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull

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

 

 

-----Original Message-----
From: Gene Heskett <gheskett at shentel.net>
To: coco <coco at maltedmedia.com>
Sent: Tue, Sep 26, 2017 10:11 am
Subject: Re: [Coco] 16/32 bit 6809 derivative

I would have added a comment, but then saw that it requires a google account. google and I parted company several years ago over their misshandling of mailing lists, and I have since moved all my mail subs to a shentel address since they (the local cable tv people) are my ISP.My comment was essentially the need for a decent barrel shifter, so that long shifts do not linearly expand the time to completion as they are used as a 1 bit shift in a loop, repeat n times now.The c compilers various parts will need massaging to make use of this.  Do the srcs for all of it as we would package it today using the improved stuff we now routinely use, all still exist? rma, rlink, cprep and the various c.opts could be merged into a new copt in the process.  We have too many competing kits for the various jobs of the c compiler now, and its too difficult to convince folks they are using broken stuffs, like the original c.prep now.I had a soap box I preached from but got ignored so much I don't preach anymore.  Everybody has to make their own bug discoveries it seems, so we need a whole new c compiler package which Just Works(TM). One that is smart enough to do register swaps for shifts as wide as, or wider than the register. That, I think would actually be more at home in a new c.opt3 module? It does make a testable speed difference in the finished binary right now. But in rzsz-3.3.6, it added several hours of handwork on the output of cc or cc2 in the middle of a compile.I had one more thing I was going to do to rzsz, convert the crc calcs from byte for byte calls, with all the overhead that represents, to one call over the whole buffer or part thereof for the final packet, that alone might have sped it up enough it could keep up with a 9600 baud link on a 6309.  But by the time I put 3.3.6 out there, I was burned out for a while and it never got done. My bad, it should have been done then.Now? Who cares?, we have other, better ways to move a file to/from the coco in the form of drivewire. Thank you A.W.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>-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco