[Coco] OS-9 Library generation

Wed May 13 05:44:36 EDT 2015

Gene, the problems I'm having with c.prep19b is all to do with memory. First is the line length. I changed that var in the source and recompiled it and got nothing but:
"Define $Tring table full"
and I have no clue how to get to that can of worms. I discussed it with Willard and he said he never got that deep into it and just had fixed a couple of things and stopped.
I got frustrated and give up as I have no time to peruse that code and learn it's ins and outs. For now, I have no problems with the MW c.prep, but I know that's just a big ? hanging in the air. I would rather work with 19b as it finds little things that mw c.prep lets slide.
So until someone comes along and puts all the memory back in, it's really useless to me.

I do agree it would be a better program, but when it don't work for me, I have to go with what does. Also keep in mind, the sources I'm compiling are no small 100 line, single source modules. Most are full to the max on what I can get in the text editor (about 475 lines) and each module averages about 20-30 sources. And yes, there's probably a lot that can be optimized to smaller code, but I can only do what I know how to do and there's no one else working on it so I do what I can do. I'm no C genius, but I've learned a lot in the past 4 years now. The code I write now looks much better than the code I started with 4 years ago :-)

You're welcome to take a look at my sources any time (I could use the advice), but be prepared for "The Spaghettiville Horror" LMAO.
Actually, it's not THAT bad, but it gets the job done.

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
Global Moderator for TRS-80/Tandy Color Computer Forums
http://www.tandycoco.com/forum/

E-Mail: ooogalapasooo at aol.com

-----Original Message-----
From: Gene Heskett <gheskett at wdtv.com>
To: coco <coco at maltedmedia.com>
Sent: Wed, May 13, 2015 4:35 am
Subject: Re: [Coco] OS-9 Library generation

The original c.prep silently runs
out of memory and builds crashing code 
only when the srcs size exceeds
something in the 11 kilobyte range.  I 
think by re-using varnames so the error
wasn't detected by later 
miss-matches.

The last 2 or 3 published versions of
rzsz came from my machine, with 
3.36 having src code totals in the 34kilobyte
area.

Stable builds cannot be done with the MW c.prep, but were rock solid with

c.prep19b.

Paul Jerkatis and I got into a regular cat fight about it at the
time 
because he was sitting on the code, trying to build it on an emulator on

an mm1 IIRC, refusing to use anything but MW pieces.  He could not also

understand that my replacements of time killing one bit shifts for an 8 
bit
shift could be replaced with a tfr b,a;clrb sequence that executed 
in 4% of the
time it took to do it in a for loop in assembly.

Paul got miffed and left when
after a month of cajoling to get that code, 
I think the version was at about
3.16 at the time, and his submissions 
crashed a real coco instantly.  He
finally did send it to me, I built it 
with my tool chain and published it 2
days later.

Then I found the code for 3.24 so I did that, and the last one was
3.36, 
each one detectably faster as I found new methods of crc calculations

via a table lookup & replaced any bit shifters of 8 bits with the above.
The
next optimization of that would have to be a major rewrite to make it 
handle
data in a 256 byte wide block, it currently goes thru the whole 
maryann for
each character received or sent.  So it is still not able to 
keep up with a
9600 baud stream of data w/o a working 7wire flow 
control.  And that we do NOT
have in the sc6551.dr driver we have today.  
aciapak.dr could do it, sacia.dr
could do it, but sc6551.dr cannot.

Willard Goosey pushed it (c.prep19b) a litte
farther out yet but I am not 
sure of exactly what he did.  Willard?  Perhaps
its fixable if the long 
line is a problem.  But I'd say that code that
consistently exceeded 127 
chars, is code that needs fixed.

By long lines of
input, how long do you consider a long line to be? I 
have not surveyed the rzsz
src codes to see what the maximum line length 
might be. I'd say anything over
256 bytes is asking way too much of a 
machine that can only address 65536 bytes
at any one instant.  I would 
not consider a line of code that was 127 bytes
long as excessive, 
however, Linus has been rather adament in keeping the linux
kernels src 
code to under 80 chars per line, using instead the C convention of
a 
space, \, linefeed, as a line extender.  But this has to be considered 
in
perspective as the default input buffer in linux is usually 32 
kilobytes.

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
list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco