[Coco] ANSI "C" for CoCo OS-9 Was: "C" Compiler C_PREP19 errors or mine?

[gene heskett]

On Saturday, May 21, 2011 10:18:37 PM Stephen H. Fischer did opine:

> Hi,
> 
> I have it almost figured out, someone may post to say how close the
> following is.
> 
> CC252, ANSIFront, C_PREP19 and perhaps C.Comp are parts of a work in
> progress to build a ANSI "C" Compiler for CoCo OS-9 that is no longer
> being worked on.
> 
> There was an attempt to allow the existing CoCo OS-9 "C" Compiler to be
> used as before, but what I discovered with C_PREP19 was a misstep or
> two.
> 
> Source code appears to be available (Commented disassembly for C.Comp I
> assume) for the parts except for ANSIFront which I have seen only the
> binary.
 
1. Ansifront is a separate function.  I had no input on that.

> The Syntax errors reported by C_PREP19 are warnings only, the code
> generated for decimal string escapes is generated correctly by the two
> part compiler.
> 
> The cprep19.doc is correct for "__DATE__", "__TIME__" and "__FILE__".
> The code was written but apparently not tested or the test failure was
> not acted on.

2. I did not personally test those functions, assuming they were correct 
when I sort of side-stepped into kicking the tires on that code.  My prime 
interest was in maintaining some semblance of 'scope' control, and giving 
it a large enough memory footprint for its variable buffers that it could 
handle compiling  rzsz-3.3.6 into a stable, functioning bit of code.  Since 
that was the biggest project (the merged srcs for either rz or sz total 
nearly 36k) anyone had ever thrown at c_prep19, and once that was working, 
I concentrated on tweeking rz/sz to gain some speed, partly by changing the 
crc methodology (good for a 170 cps speedup) and by exploring some of the 
6309 only stuff that on my machine, got it up to around 730 cps/second.  
This was without allocating a block sized buffer so that a 256 byte block 
could be received, then the crc function applied to the block of data while 
the ACK was held until the crc check was done.  That would have probably 
allowed it to work at 38.4 kilobaud, and achieved 1000+ cps average speed.  
Table lookup derived crc's can be a whole lot faster than Chuck Foresbergs 
original one bit at a time shift method.  I can speed parts of that up by 
nearly 16x, but table lookups still beat it by a large margin.

IMO, running on a cpu without a barrel rotator to do shifts, and not having 
a 'void' type for throwaway data, expecting this compiler to meet ANSI 
specs in every aspect, when it was written in the middle/late 80's, yonks 
before a C89 ansi spec was ever carved in paper stone by K&R's 2nd C book, 
is asking for nearly a total rewrite.  Ansifront-0.12, by converting void 
to int in front of c_prep, helps a lot.  If ansifront is used properly, at 
least 98% of the ansi compliant code out there will build and run on the 
coco's os9.  And for those who understand assembly, cc252 can be stopped at 
the end of c.opt, the code inspected, and probably 90% of the sex commands 
removed with no ill effects, and a further smallish speedup.

Likewise, long bit shifts can be nuked in favor of TFR's.  But the compiler 
doesn't know that.  You have to do that yourself.

> I was able to transfer testcp19.c to my oldest laptop and after
> commenting out a few lines the program compiled using Borland Turbo C++
> and ran. (ANSI Compiler)
> 
> The output included the file name (Full Path), date and time. What is
> wrong is "__DATE__", "__TIME__" and "__FILE__" should include quotes
> when inserted just like the next line in this post.
> 
> "testcp19.c", "May 21 1911" and "07:04:30". The project stopped before
> Y2K thus the incorrect year.

Separate problem.  For that fix, the clib function for the date will need 
'adjusted'.  AFAIK, the 6 byte time package in page 0 is not changed, only 
the method of deriving a date with an extra 100 years added was actually 
changed, in the clock module, and in the date executable.  I did it, 2 or 3 
others did also, and I have NDI whose version actually lives in the clock 
module today.

But IIRC, the date function in clib.l grabs that time/date packet directly 
from DP(0), so it IS going to be wrong.

> --------------------------------------------------
> 
> As I have noted new persons have joined us lately, perhaps the project
> can be
> continued. (Quick, find the source for ANSIFront).
> 
> SHF

Find Vaughn Cato, who was at one point at <gcato at sc6000.sct.edu>
It is his code.  Googling says there are those names, unforch, quite a few 
of them link to an obituary at some place in IL, but that one is much too 
young, so I would vote for the one born in '69, whose name is all over the 
IMDBase.  That fits the imaginary profile I have of him in my mind, not 
that its correct.


[...]

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
<http://tinyurl.com/ddg5bz>
<http://www.cantrip.org/gatto.html>
The lunatic, the lover, and the poet,
Are of imagination all compact...
		-- Wm. Shakespeare, "A Midsummer Night's Dream"