[Coco] [Color Computer] Multiple C compiler projects

[James Jones]

Gene Heskett wrote:
> Now you've asked the 64 million dollar question, James.  I don't 
> recall ATM.  I'll have to go dig around in the boxes in the basement 
> I expect.  What I do recall was the difficulty I had in making it 
> work because Lonnies daisy wheel printer he used for making the press 
> plates scans used an el character that was identical to a one 
> character.  And one of my earlier daisy wheel printers did too, so I 
> wound up grinding a piece off the bottom of the el so I could tell 
> the difference.  My zerox 1650-ro has an easily discernable 
> difference.  I'll see if I can find it, but its earlier, say 1986ish 
> as I think as I was living in a trailer by myself in a small town NE 
> of Clarksburg called Hepzibah at the time.  Back in about half an 
> hour if I'm lucky... 

Yow....Thanks for going to the trouble of tracking it down.

> Found it, April 1986, starting on page 240.  (Gee, the Rainbow really 
> was a big magazine back then) The code has some semi-circular 
> references, so that when merging to make the library, there are a 
> couple of routines that need to be included twice as the linker, 
> c.link, only scans the library once.  So I think the version I have 
> on my hard drive probably has 2 copies of several of the routines in 
> it.

> One could probably re-arrange the merge order even more and alleviate 
> the need for the dups if enough effort were expended.

Yup. Before I went to work for Microware, I wrote a program that emits 
the dependencies as a sequence of lines that describe the dependencies, 
suitable for feeding to a topological sort to either churn out the 
appropriate linearization if it's a kosher partial order, or complaining 
if it isn't. I made the sources public, so they should be out there for use.

> The data format was compatible with the microware printf, that much I 
> do recall.  Where does that extra significant bit show up in the 
> printf output?

It depends. It may not show up in printf() output. Relatively few 
floating-point numbers can be accurately printed in decimal (in the 
sense that if you scanf() the printf() output you get back the same bit 
pattern you started with).

Floating point calculations come off the worst when you subtract one 
value from another value that is almost equal to the first, because the 
difference only has as many significant bits as differ between the two 
values. The IEEE trick for keeping another significant bit in normalized 
values thus pays off more in calculations than in I/O.

	James Jones