[Coco] Climax C Compiler setup

[Bill Pierce]

Walter, as one who went through all this a few years back, I made a few observations and voiced them here on the list only to be flamed for going against the grain.
The version of c.prep in the so called "Climax" release (version 1.4c?) is definitely more "robust" and catches more errors... BUT, if one goes back to the sources (which as you mention cannot be compiled "as is"), you'll find many notes... notes that stated "Line length has be reduced", "buffer size has been reduced" "maximum number of labels has been reduced" etc, etc, etc.
All this was done to make room for the "enhancements". The only problem is it becomes useless when compiling very large sources and huge multi-source projects... like the components of the compiler system itself which will not compile... none of it.
And the Ansi front... It states in the very notes with the source that it was never finished. Ok, so I can only compile code written in "part ANSI"?
I'm not sure about the c.opt, but I will bet anything it suffers the same problem as c.prep, so I avoid it.

For Coco OS-9 C, I'll stick with straight K&R (at least what parts are supported).
Here's my C compiler system that I use to compile Ultimuse3 and MShell:

rcr: A custom front-end that allows the use of c.comp and ram disks. I have the source, so I modify it when I need different components. (Michael J Knudsen)

c.prep: I use the original as 1.9a-c all fail on my sources. (Microware)

c.comp: combine c.pass1 & c.pass2 which seems to run faster and also requires less cmd line real estate There are 2 versions of this file, one on Gene's site, and one one in the NitrOS9 repo. There is only a one byte difference in them [buffer size variable?] and the one in the repo works (Microware?)

CnoY: a really cool utility that massages the resulting asm source to make the end code faster (Michael J Knudsen)

c.opt: Again, I use the original for the same reasons as c.prep. (Microware)

rma: RMA supposedly fixes a few bugs that were in the original c.asm and also worked better as a stand alone REL compiler. (Microware)

rlink: Same as above (Microware

touch: again, supposedly a few bug fixes (Tim Koonce?)

For libraries/headers, I use:
clib/clibt: both by Carl Kreider
cgfx(7): the ultimate graphics library for level2 (Mike Sweet)

And finally,
make: by Time Koonce

BTW... I do NOT use any of the above versions from the Climax project as they are not the originals and have been "recompiled". Most of what I have came from the RTSI site from their original LZH uploads, Mike Knudsen, the Microware C Compiler disks, and the Microware Developer's System disks.

The big difference? The stuff I use WORKS! I use it all regularly and I did try everything that is out there and found what worked the best for what I was doing.
 
 
 
-----Original Message-----
From: Walter <zambotti at iinet.net.au>
To: 'CoCoList for Color Computer Enthusiasts' <coco at maltedmedia.com>
Sent: Sun, Mar 24, 2019 2:46 am
Subject: Re: [Coco] Climax C Compiler setup

Missing header files <string.h> & <memory.h>.

I can't recompile c_prep because there are includes to non-existent header files.

These don’t seem to be on the Climax CoCo C Compiler disk.

Anyone know where they might be?

Walter

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Walter
Sent: Sunday, 24 March 2019 2:01 PM
To: 'CoCoList for Color Computer Enthusiasts'
Subject: Re: [Coco] Climax C Compiler setup

Bill G is correct. In OS/9 EOF is not a character.

C_prep uses I_readln to read a line of text terminated by an EOL upto a maximum buffer length.

If the buffer length is exceeded a text to long error is returned.

The code then checks to see if the last character on the line is a EOL '\r'.  If it is not is then assumes the line is too long
and returns a line to long error manually.

This is a bad assumption.  It should only assume this if the line read back has no EOL and equals the maximum buffer length.

After all most of the last lines in my source code is usually just  "}"  . Which is just one character and is way shorter than the max line length.

If it is shorter the max line length it should just append a null to the buffer and return.

I am looking at a fix now!

Walter

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Bill Gunshannon
Sent: Saturday, 23 March 2019 7:04 PM
To: coco at maltedmedia.com
Subject: Re: [Coco] Climax C Compiler setup

On 3/22/19 11:28 PM, Stephen Fischer wrote:
> OS-9 does not heed EOF.
> 
> That's a MSDOS \ Windows thing which bit me several times, it took some 
> time to realize why documents were truncated when I first used MSDOS 3.3.
> 
> End of Text (ETX) is $03, I do not see EOF in the ASCII charts found by 
> Google.
> 

EOF is not always a character.  EOF is end of file and how it is
determined is system dependent.  Even DOS/Windows is inconsistent
in this regard as it used both ^Z or an length mentry in the
directory to determine EOF. Characters like ETX were intended for
data transmission and communication device control.  Some have
been used for other things, but don't expect that use to common.
EOL is done many ways.

bill



-- 
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