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

[Walter Zambotti]

Bill

in relation to rma adding a 0 to the end of file.  Is this for the 
rma/r63 that runs natively on OS9/Nitros9?

Walter

On 4/5/20 11:29 pm, Bill Pierce via Coco 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>.
>