[Coco] C compiler self-hosting on NitrOS9 again!

[Bill Pierce]

Jeff, you apparently do not know how to compile the C libraries.

The libraries are linked LATER when you compile a C program NOT when they are created.

>From the Microware OS-9 C Programming Manual:-----------------------------------------------------------
Compiler Option Flags
-R - Suppresses linking library modules into anexecutable program. Outputs are left in files with postfixes .r.-----------------------------------------------------------
Also from the Microware OS-9 C Programming Manual:
-----------------------------------------------------------
 A library consists of a group of C procedures or functions that havebeen separately compiled into Relocatable Object Files (ROF) andsubsequently merged into one library file.If, hypothetically, you had created a set of higher level mathematicfunctions, that you wanted to convert into a C library. First youwould separately compile each one using the —R option. Then youwould merge them all into one large library file. If you need to scanthe library file for available functions you can use the exampleprogram RDUMP.C to inspect any C library file.For example: 0S9:CC1SIN.C COS.C TAN.C ARCOS.C -R 0S9:CC1 ARCSIN.C ARCTAN.C EXP.C LOC.C —R 0S9:CC1NLOG.C SQRT.C SQR.C CUBE.C —R
 Thenyou would: 0S9:MERGESIN.R COS.R TAM.R ARCOS.R >TEMP1 0S9:MERGEARCSIN.R ARCTAN.R EXP.R LOG.R >TEMP2 0S9:MERGENLOG.R SQRT.R SQR.R CUDE.R >TEMP3 0S9:MERGETEMP1 TEMP2 TEMP3 >TRIG.L-----------------------------------------------------------------

AS I said, no rlink/c.link involved.
The whole process above using the original "CC1 -R" is:
c.prep, c.pass1, c.pass2, c.opt, c.asm (-R suppresses the linker)
This creates the ROFs that are merged for library files.

The whole point I was trying to make is that if you use RMA to create the ROFs used for the library (not a binary executable), RMA adds an extra "0" to the endfile byte sequence in each ROF, which is normally (hex) "00 39 00 00". After assembling with RMA it's (hex) "00 39 00 00 00". Each ROF in the merged file will be like this. I have checked them with a hex editor and verified this. Nothing will ever show an error in this process.

Now, when you DO use the merged library file in compiling a binary executable using "rlink program /dd/lib/cstart.r file1.r file2.r -L/dd/lib/xxx.l", it will fail. It will also fail trying to use rdump on them.

The reason it fails is that RMA added the extra "0". When Rlink scans through the lib file to find the desired subroutine (called from the C code), it uses the end sequence of "00 39 00 00" to find the next module in the lib file. Once found, it assumes the next byte as the subroutine header. If RMA was used to build the lib, then the linker finds the extra "0" instead and errors. This ONLY occurs if libraries are originally compiled with RMA. It does NOT affect ROFs being linked into binaries, only the merged library you are attempting to link.

The most likely reason you've never seen this is that you probably use the precompiled libraries. All of the old libraries (Tandy clib.l, CK's clib.l, & MS's cgfx.l) were compiled with the original standard Tandy/MW compiler (w/c.asm).

The only other thing I could say about this is for you to compile a library using RMA, then use that library to compile a C program. It WILL fail.
I have gone through each ROF (assembled with RMA) to be used in the library (before merging) and deleted the extra "0" from each ROF and the resulting merged library worked properly.

As for the "c,prep", there has been c.prep18, c.prep19, c.prep19b, and c.prep19c. I have the sources for all of these.
All of the above will probably work fine for "most" people. I just can't use them to compile MShell or Ultimuse3. The reason being that in adding all the extra features (and fixing bugs), the line length and label count were reduced to make room. This is actually stated in the opening comments in one of the sources of the above files (I can't remember which, but I think it's c.prep18). Each one is just a tweeked version of the previous one.

The same problem exists in the tweeked version of c.opt.I can't remember the version number, but I do have it and it's the only one I've found other than the original Tandy version.

As I said, both of the above would work for most people, just not for me due to the complexity and size of both Mshell and Ultimuse3 sources.

There are 2 versions of c.comp that I know of (and no working sources). One from Gene Heskett's site, and one from the NitrOS9 repository C compiler.
They are identical with the exception of a single byte (verified with a hex editor) which appears to be buffer size or something similar. The one from Gene's site has a smaller buffer than the one from the repo and I cannot use it. It errors on compiling Ultimuse3 or Mshell with an out of memory error. The one from the repo does not.

I am not trying to argue a point with you but just trying to inform you of things I found while spending about a year collecting C compiler binaries and sources, in trying to create the perfect NitrOS9 C Compiler for my usage. I have a 128meg HD image (vhd) about 2/3rds full of nothing but various C compiler systems and their sources (I just added your system). I have at one time or another, compiled and tried each and every one of the systems as well as combinations of each. In these experiments, I found quite a few limitations as well as a few bugs (all logged in text files for each system). I finally settled on the combination as I listed as that worked for ME. My system is not for everyone. I don't know of anyone compiling anything as complex or as large as MShell, which in it's current state, compiles over 250 sources from one simple script.

This is the last I will post of this as I will stick with my results from extensive testing until someone can prove to me that they can create C library files (not executable binaries) using RMA.

Bill P.

-----Original Message-----
From: Jeff Teunissen <deek at d2dc.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Mon, May 4, 2020 10:38 pm
Subject: Re: [Coco] C compiler self-hosting on NitrOS9 again!

On Mon, May 4, 2020 at 7:46 PM Bill Pierce via Coco
<coco at maltedmedia.com> wrote:
>
> Jeff, rma & rlink work fine, I use them exclusively.... UNLESS you are building library files (in which rlink is not involved).
> To build a library (like clib.l or cgfx.l), using the "clib" sources, you would think you could use c.prep, c.comp, c.opt, then rma (for "*.c" files, if it's a "*.a" file then only c.opt and rma). The resulting rofs are then merged (not linked) to form the "*.l" file to be used in c programming.
> When rma is used, the resulting *.l file will be unusable.

You keep saying "rlink is not involved", but it is. Since rlink is the
thing that does the linking of binaries, if rlink can read the ROF
files in the library (which, at least on my machine, it seems to be
able to), it can link the binary using the library.

> My C environment is:
> rcr - custom C frontend
> c.prep - original Tandy (any others fail on long lines and too many labels)

I only know of one other, c_prep, and that one is not very good. cpp,
on the other hand, I have not yet been able to break (but I haven't
tried all that hard). It can handle source code with nice long lines
that the old c.prep barfs on, while having the ability to deal with
more modern preprocessor features (like "#if defined(FOO) || defined
(BAR)", or "#if FOO == TRUE").

> c.comp - ??? unknown origin ??? (I use the one from the NitrOS9 repo)
> CNoY - custom massager only used on certain projects
> c.opt - Original Tandy (all updated vesions suffer same problem as c.prep)

The version of c.opt in the CoCoC repository has all of the
optimizations the one from Tandy included, plus a couple of new ones.
I am planning to add an option for it to do the "CnoY" thing as well
as its ordinary optimizations, so it can be done all in one pass. It
will probably use a "-2" argument to enable Level 2-specific
optimizations like CnoY.

-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco