[Coco] OS-9 Library generation

Tue May 12 23:19:12 EDT 2015

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:

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