Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!bionet!ames!lll-lcc!pyramid!wendyt
From: wendyt@pyrps5 (Wendy Thrash)
Newsgroups: comp.sys.pyramid
Subject: Re: gcc for Pyramid
Message-ID: <68877@pyramid.pyramid.com>
Date: 4 May 89 18:41:11 GMT
Sender: daemon@pyramid.pyramid.com
Reply-To: wendyt@pyrps5.pyramid.com (Wendy Thrash)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 47

Warning:  Opinions expressed in this article are mine, not Pyramid's.

Eric Lee Green writes:
>I suspect what they're more interested in is preventing the making of
>Pyramid-clones (as if anybody would want to!). The main thing needed
>to port Unix to a new computer is a "C" compiler... having a
>Pyramid-compatible "C" compiler would thus make it that much easier.
>Still, any decent compiler expert could re-target gcc to the Pyramid
>in maybe a month or so of full-time work... so I'm still puzzled.

I honestly don't think Pyramid is worried about a sudden onslaught of
Pyramid clones.  There may be some details of the architecture, which
may be spelled out in the architecture manual, that might help competing
companies discover any Pyramid secrets that would give the company a
competitive advantage.  Corporate realities being what they are, however,
it is highly likely that any company that would be interested in such
information already has as many copies of our architecture manual as
it wants, nondisclosure agreements notwithstanding.  Nevertheless, if
Pyramid wishes to maintain trade secret status on certain things, I
believe that it must make a reasonable effort to protect them.

The other argument against publicizing details of the architecture is
that minor details of the architecture are subject to change.  A "minor
detail" is one that will not affect any Pyramid software or the software
of our software vendors, or one that we're willing to retrofit.
For example: A long, long time ago, in a galaxy far, far away, there was a
certain floating-point exception that behaved in a certain way.  The way
it behaved matched the architecture manual, but it was wrong (i.e. it was
not in accordance with IEEE754 and was not an intentional deviation from 754;
somebody just made a mistake).  The mistake was discovered internally,
microcode was changed, and the architecture manual was updated.  Everybody
who had a copy of the architecture manual had agreed that such a change
was reasonable, so it was made with no fuss, no muss.  This was just a
fable, of course, but that's how I think it's supposed to work.

Pyramid's failure to provide gcc is pretty simple to explain.  We
considered porting gcc.  We decided that we would rather do a new
optimizer and code generator than modify our front ends (for C, Pascal,
f77, and Ada) to work with gcc or support a second code generator and
optimizer.  We could have provided gcc has an option, but that would
have committed us to years of support for an additional C compiler.
Junking the old C compiler would not have been an option, as gcc and
Pyramid cc differ in subtle and mysterious ways, and there are
mountains of code out there that run when compiled with Pyramid cc but
might not run if compiled with gcc.  It's hard for us even to fix old
bugs without upsetting customers who've come to depend on a particular,
bizarre behavior.