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

Mon May 4 19:46:10 EDT 2020

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.

My C environment is:
rcr - custom C frontend
c.prep - original Tandy (any others fail on long lines and too many labels)
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)
rma - original Tandy or R63 (either works)
rlink - original Tandy
I also use TK's make, CK's clib.l and Mike Sweet's cgfx.l.

To build C libraries, to get working libraries I have to use.
c.prep
c.pass1 & c.pass2
c.opt
c.asm
(c.link is not used for libraries)
all from the original Tandy compiler

I tried many combos and this is the only build tree that worked for C libraries. Also, the only way I could match the crc of CK's clib.l was with the original Tandy compiler. Same with Mike's cgfx.l.

Have you tried building the library sources in your repo into the "x.l" files they are intended to become? If not, try it some time. It's an interesting experience.

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

I don't know exactly what's going on in your environment, but the
version of rma I am using and the version of rlink I am using seem to
be able to work together. RMA definitely outputs a different ROF
format than C.ASM does (version 1 vs. version 0), and C.LINK can't use
it, but the RLINK I am using seems to be able to.

At this point, using cc09 is for people who are able to fix problems
themselves, because I do not have a 'cc' set up yet to call 'cpp' as a
preprocessor instead of c.prep or c_prep, and 'cc09' instead of c.comp
or c.pass[12].

I'm not particularly worried right *now* about how much RAM it uses,
because there are configurations that are significantly smaller than
the old Tandy compiler. For example, by disabling the profiling
support (the -p option) when compiling it, the compiler binary shrinks
by about 300 bytes. By disabling register tracking, the compiler
shrinks by about 2.25K (but produces slightly worse code). And by
disabling floating-point support, it shrinks by much more, to enable
_really_ complex functions.

On Mon, May 4, 2020 at 6:29 PM Bill Pierce via Coco
<coco at maltedmedia.com> wrote:
>
> Jeff, I don't use c.link, I use rlink and that was what caused me to find the problem with rma. Everything seems to be fine until you either tun rdump on the library or actually try to use it in a C source which will error with "file not found" when rlink runs.I had to revert back to c.asm and c.link to get valid library files. This ONLY affects library files because they are merged rofs and rlink uses the endfile 0 to find the next module in the merged library. Rma works in regular C files when using multiple sources for one file because C uses direct addressed jumps to the subroutines and the linker uses the labeled references. The libraries created with rma still will not work even then.
> I have not tried this with your compiler system yet, but I will try and see if it will produce the library files correctly.
>
> I plan to create some custom libraries for easy access to virtual memory modules and hot-swappable subroutines as used in MShell & Ultimuse3.
>
>
> -----Original Message-----
> From: Jeff Teunissen <deek at d2dc.net>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Mon, May 4, 2020 4:10 pm
> Subject: Re: [Coco] C compiler self-hosting on NitrOS9 again!
>
> You are correct in that if you want to be compatible with the C.LINK
> linker, you can't use RMA to assemble source code, because RMA
> produces version 1 ROF files, and C.ASM produces version zero ROF
> files, and the older linker can't use the output of the newer
> assembler.
>
> I do not have the source code to C.LINK (which is itself an old
> version of rlink), but Tim Lindner wrote a version of RLINK in C that
> I am going to work on getting working on native OS-9...and then I will
> be using that linker to put binaries together, because source code is
> always better than no source code.
>
> On Mon, May 4, 2020 at 11:29 AM Bill Pierce via Coco
> <coco at maltedmedia.com> wrote:
> >
> > Also, if you are using rma to compile the C libraries, they will fail. You must use c.asm (and possibly c.pass1 & c.pass2).
> > I've tried all versions of rma to compile the libraries, but rma (for some unknown reason) adds an extra 0 (zero) to the end of the binary which when merged with other "rofs" to make a library (they are not linked, only merged), makes it impossible when compiling a C project, for rlink to find the specific modules within the library file. RLink uses the endfile zero to find the "next" module in the library file, and in finding the first 0, it assumes the next byte is the beginning of the next module and errors due to the extra zero. The easiest way to check for this, is to build a library file, then use rdump on it. If it is plagued by the extra zeros, it will tell you that it is not a valid library file and abort.
> > I've found the best way to create the libraries is to use the original Tandy/MW compiler system.
> >
> >
> > -----Original Message-----
> > From: Jeff Teunissen <deek at d2dc.net>
> > To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> > Sent: Sun, May 3, 2020 11:36 pm
> > Subject: [Coco] C compiler self-hosting on NitrOS9 again!
> >
> > Some of you know I've been hacking on the "C3" compiler that's been
> > bouncing around, and anyone else who's played with it knows that it
> > doesn't really work right.
> >
> > Well, it does now. :)
> >
> > In the "CoCo C" repository on GitHub is a K&R C preprocessor and
> > compiler that can be built (in a multi-stage process requiring the old
> > Tandy compiler to start from), that is also capable of compiling its
> > own code, so we can produce a new version of the compiler by using its
> > own code.
> >
> > The code it produces is slightly more efficient than that produced by
> > the Tandy compiler, so as far as I can tell will almost always produce
> > smaller binaries.
> >
> > Note: the code _also_ compiles on modern x86 systems, but the
> > resulting binaries don't produce working code -- there are endianness
> > problems that need tracking down before it will be a good
> > cross-compiler. If anyone locates the code that's producing the
> > errors, let me know. :)
> >
> > It's available at <https://github.com/Deek/CoCoC>.
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco

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