[Coco] 16/32 bit 6809 derivative

Tue Sep 26 23:51:33 EDT 2017

Gene, I meant c.prep19-19c, not 14. Those were yours and Willard Goosey's edits and those are the ones that run out of line memory and label memory. It's NOT memory errors, but "Line too long" and "Out of DEF_NODE space" (definition label references), which are both buffer errors. The source for c.prep 18 that was originally modified (by Jim McDowell) has notes stating that buffer space was reduced. I guess you would call this "limitations" and not "bugs", but in my case, totally unusable.

Here's the notes from the docs:

Version 1.8 has the following limitations:

  * Maximum line length is 250 characters.  This is less than the ANSI recommendation but cuts in half the needed memory.  It should suit most programmer's needs, but can be changed by changing the variable LINEMAX in cp.h and then recompiling.
  * Maximum memory allocated for definition data is 6500 bytes.  This can be changed by STRNG_TBL_MAX in cp.h.
  * Maximum number of arguments allowed in a macro (#define) is 4.  The maximum length of each argument is 120 characters.  This is less than the ANSI recommmendation but should suit most needs.  These limits can be adjusted by changing MAX_ARGS and MAX_LENGTH in cp.h.
  * Maximum number of nested #if statements is 8.  This is the ANSI standard.  It can be changed by MAX_NEST_IF in cp.h.
  * Maximum number of nested #include statements is 8 levels beyond the root file.  This can be changed by MAX_INCLUDE in cp.h.
  * Maximum number of definitions allowed is 400.  This can be changed by MAX_DEFS in cp.h.
  * #include <> statements look for files in /DD/DEFS directory.

Changing ANY of these values as suggested results in overflow or memory errors in trying to compile c.prep, or creates a file that crashes when run, so apparently, the additions grew too large to allow the buffers to be set back to the standard size.
These values also persisted through all later revisions (yours & Willard's).

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 8:54 pm
Subject: Re: [Coco] 16/32 bit 6809 derivative

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>coCheers, 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