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

Bill Pierce ooogalapasooo at aol.com
Mon May 4 18:28:59 EDT 2020


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


More information about the Coco mailing list