[Coco] OS-9 Library generation

Wed May 13 04:34:32 EDT 2015

On Tuesday 12 May 2015 23:19:12 Bill Pierce via Coco wrote:
> Stephen, I see what you're getting at. TK's "make" was probably well
> after that phase of your programming, and the MW Dev Sys package
> didn't come out until what, 88? 89? And yes, I have all the stuff from
> Willards site... it's where I got the whole clib.l & cgfx7 sources.
> And as I stated, I AM building the entire source, not just a module or
> two. The whole extra 2 bytes problem seems to stem from the latest
> version of RMA and ONLY applies to building libraries as the linker
> fixes the problem when building "standard" C or RMA code using
> singular ROFs. I hope to have the libraries building correctly as soon
> as I solve the extra byte problem. Other than that, they build
> perfectly.
>
> BTW, "merge" or "cat" is much simpler for lib files than os9gen. Use
> the same file list and files. Just no hassle with all the bootfile
> stuff. It's how the originals were done. Just read CK's makefile for
> clib.l. "Merge (or cat) [filelist] >clib.l" and you're done :-)
>
> The components to my current C compiler are listed and well documented
> on my website on the "MJK C Compiler System" page. I have currently
> discontinued use of c.prep19b, and reverted back to the old MW c.prep
> because c.prep19b pukes on very long lines in the sources and
> allocated memory was cut to make room for features (it's in the docs).
> The changes made in my C system are as follows:
>
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.

> rcr - custom front-end (replacing cc1 or cc2) by Mike Knudsen
> c.prep - standard MW edition
> c.comp - custom combined c.pass1 & c.pass2 making it a single pass
> compiler, from the NOS9 repo CNoY - custom source massager by Mike
> Knudsen (reduces cpu cycles and code size) c.opt - not sure whether
> it's MW or c.opt2.5 at the moment
> rma - NOS9 repo version
> rlink - NOS9 repo version
> touch - custom version by Mike Knudsen
>
> Also:
> make - by Tim Koonce
> cstart.r - by Carl Kreider
> clib.l - by Carl Kreider
> cgfx.l - by Mike Sweet
>
>
>
>  The whole system builds stable program modules and gives me no
> problems. I tried several combos of systems before settling on this
> one. The whole MShell software suite is compiled from one make script
> which runs about 8-10 makefiles, compiling almost 200 source files
> (and growing fast) in one sweep. On a real Coco, we're talking 5 or 6
> hours (maybe more) of compile time. On Vcc overclocked to 71mhz, we're
> talking about 20-30 seconds of compile time :-) Much less if only
> compiling new edits (automatic).
>
> All developement, editing, compiling and testing is done in NitrOS9
> running in VCC with extra testing on a real 1 meg Coco 3 running
> NitrOS9 (6809). No PC tools or cross-compilers needed or wanted.
>
> It's the most stable and fastest system I've found yet.
>
>
>
> 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: Stephen H. Fischer <SFischer1 at Mindspring.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Tue, May 12, 2015 9:52 pm
> Subject: Re: [Coco] OS-9 Library generation
>
>
> You have the 40mm cannon pointed in the wrong direction.
>
> The routine I used
> to split the library I think also wrote a text file with the names of
> the modules in the library.
>
> Facing doing a merge of 40 - 70 modules and perhaps
> doing it with several merges hopefully using a ShellPlus script was
> something that could not be done successfully even with a list of the
> modules in the proper order. That was the 40mm cannon pointing at the
> project.
>
> As I was
> building System disks using OS9GEN and could edit text files at that
> point the OS9GEN solution presented itself and worked quite nicely.
>
> All I needed to do
> was to change one number in the "abort" module so the entire program I
> was trying to fix was included in the "Core" dump.
>
> The bug made the "core" dump
> short by one (1).  Thus constant problems looking at the "Core" dump
> and the C.Link generated loader map. (WHAT? C.Link generates loader
> maps!)
>
> I doubt if
> you care but I have attached Abort.zip to this e-mail. Dated 7/1/1986.
>
> I am
> unsure if the fix is in this file but every library in use "may" have
> this bug except the ones I made and used.
>
> ------------------------
>
> I do not think
> "Make" was on my radar at that point but if the entire library needed
> to be assembled / compiled Make would be the only way to go. I started
> using "Make" as soon as I saw it.
>
> It's the use of OS9GEN with the file list in a simple text
> file was what I wanted to add.
>
> ------------------------
>
> The second phase
> of the C Complier project that I never finished was for lack of
> directions from any direction for what to include.
>
> You perhaps are doing that phase, one that
> needs to be done. There are way too many versions of libs available
> and no clear instructions.
>
> Willard just listed all the libraries available and I did not
> figure out a plan.
>
> http://www.tandycoco.com/forum/viewtopic.php?p=528#p528
>
>
> Adding your final .dsk(s) and how you chose what to include would make
> the project complete.
>
> SHF
>
> ----- Original Message -----
> From: "Bill Pierce
> via Coco" <coco at maltedmedia.com>
> To: <coco at maltedmedia.com>
> Cc: "Bill Pierce"
> <ooogalapasooo at aol.com>
> Sent: Monday, May 11, 2015 11:28 PM
> Subject: Re:
> [Coco] OS-9 Library generation
>
> > Stephen, I using sources to make "new"
>
> libraries, not fix old ones. So your 40mm cannon to kill a mouse
> technique is useless. A makefile is much simpler and more efficient.
>
>
>
>
>
>
> Bill Pierce
>
>
>
> --
> Coco mailing
> list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco

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>