[Coco] 16/32 bit 6809 derivative

[Gene Heskett]

On Tuesday 26 September 2017 23:51:33 Bill Pierce via Coco wrote:

> 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).
>
I don't doubt you bill, but I never ever ran into that error in building 
the biggest thing I built with it.

Humm, I wonder if my vfy could fix that, it can reach into a module of 
code and adjust the size of the memory it requests from the system at 
startup time. Adding another few kilobytes to that value might be just 
what the doctor ordered. vfy will spit out its help screen if you don't 
give it any auguments.  That help should explain how to do that.

Let me know if it helps.
>
>
> 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/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>