[Coco] 16/32 bit 6809 derivative

Tue Sep 26 20:53:28 EDT 2017

On Tuesday 26 September 2017 11:14:36 Bill Pierce via Coco wrote:

> 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.

I did c.prep19 precisely because of that, Bill. There is yet a newer one, 
but I have not tried it with src files approaching 40kb. I know for a 
fact it has no problems with 34 to 35 kb src files. But for some reason 
very few will touch it, the usual refrain being that MicroWare's code 
s/b the reference implementation. It can't possibly have bugs. Its worse 
than a 10 day old road kill in early August. It might be, but go try and 
build something whose src files exceed about 12kb. No reported errors, 
but the output WILL crash your machine.

> 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).

Not that I know of.

> 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.
rlink is the newer, c.link is what shipped when you bought the compiler 
from the shack. Also the assembler shipped was c.asm.

> 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).
>
Why touch?  Seems odd.

> 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/co
>co

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>