bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (04/13/89)
In article <1032@nixctc.DE> pete@relay.NixCtc.de (Pete Delaney) writes:
Has anyone looked at a gcc implementation for the Pyramid?
I understand that it was done inside Pyramid, mostly as an exercise in
curiosity, and it worked fine. Last I heard, Pyramid was uninterested
in releasing it because it would reveal too much proprietary
information about their system.
Sounds like someone else outside Pyramid will have to go ahead and do
the work again.dglo@clash.ADS.COM (Dave Glowacki) (04/13/89)
In article <BOB.89Apr12152036@allosaur.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >In article <1032@nixctc.DE> pete@relay.NixCtc.de (Pete Delaney) writes: > Has anyone looked at a gcc implementation for the Pyramid? > >I understand that it was done inside Pyramid, mostly as an exercise in >curiosity, and it worked fine. Last I heard, Pyramid was uninterested >in releasing it because it would reveal too much proprietary >information about their system. It was mentioned at the Pyramid Users' Group meeting last June as a possible future direction. >Sounds like someone else outside Pyramid will have to go ahead and do >the work again. Unfortunately, the documentation on their architecture is only released under non-disclosure agreements. I suppose you *could* reverse-engineer everything with lots of "cc -S" runs... -- Dave Glowacki dglo@ads.com Advanced Decision Systems
csg@pyramid.pyramid.com (Carl S. Gutekunst) (04/13/89)
>> Has anyone looked at a gcc implementation for the Pyramid? >> >>I understand that it was done inside Pyramid, mostly as an exercise in >>curiosity, and it worked fine. Eh? I *thought* I knew everyone who was playing with gcc here, and I've never heard of anyone doing a gcc backend for the 90x CPU. I can ask around, though. >Last I heard, Pyramid was uninterested in releasing it because it would >reveal too much proprietary information about their system. That would be a pretty silly reason. ;-) If someone at Pyramid were to do a 90x gcc backend, it wouldn't be released because: (a) there would be no point in supporting it, since Pyramid already has its own C compiler; (b) Pyramid does not ship software that isn't supported. <csg>
jonathan@comp.vuw.ac.nz (Jonathan) (04/14/89)
In article <BOB.89Apr12152036@allosaur.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >In article <1032@nixctc.DE> pete@relay.NixCtc.de (Pete Delaney) writes: > Has anyone looked at a gcc implementation for the Pyramid? > >I understand that it was done inside Pyramid, mostly as an exercise in >curiosity, and it worked fine. Last I heard, Pyramid was uninterested >in releasing it because it would reveal too much proprietary >information about their system. > >Sounds like someone else outside Pyramid will have to go ahead and do >the work again. It's been done already. I had gcc-1.31 bootstrapped (ie, stage2==stage3) on a Pyramid 90x in mid-January. The machine description itself seems to work, although it's unpolished; it doesn't seem to compile GNU Emacs correctly. And since Pyramid's dbx debugging info is unlike anyone else's, debugging it has been quite hard. (I haven't finished porting gdb yet.) I'd like to follow the terms of my GNU CC license and make the Pyramid machine description I have freely redistributable. I also understand that Pyramid regards their machine architecture as proprietary, and I'm unwilling to cause myself hassles. Is there any reason not to distribute what I have? Perhaps someone from Pyramid would like to comment?? Should the gods be willing, I'm sure we can arrange some means for distribution to the world at large. (I'd like some people to help fix the bugs, too; I've been hoping to give this to the guys at osu-cis for months.) Just as as an aside, I don't understand what Pyramid regards as proprietary about their architecture. Given: - a C compiler that can generate Pyramid assembler code - a list of valid opcodes (hint: strings -2 /bin/as :-)) - a means of determining what combinations of opcode and operand are valid (/bin/as) - a method to determine how the insns and operands are encoded (eg, a debugger that will display data as either hex numbers, run on "opcode Rx,rx" and variants), - Useful documents like the OSx Porting Guide it's easy enough to decrypt enough information about the architecture to build a compiler -- and even a table-driven disassembler. Which doesn't leave much of the "architecture" to discover. As my professor said, "If you can do it, then Pyramid's competitors can..." -- ----------------------------------------------------------------------------- sane mailers: jonathan@comp.vuw.ac.nz | Industrial democracy: UUCP path: ...!uunet!vuwcomp!jonathan | One factory, one vote!
csg@pyramid.pyramid.com (Carl S. Gutekunst) (04/15/89)
In article <14644@comp.vuw.ac.nz> jonathan@comp.vuw.ac.nz (Jonathan) writes: >Is there any reason not to distribute what I have? PERSONAL OPINION: It seems to me that if people can reverse-engineer the IBM PC BIOS ROMs and sell them, you can certainly take your reverse engineered gcc backend and give it away. > Just as as an aside, I don't understand what Pyramid regards as > proprietary about their architecture. Back when I was a customer, I squawked about this to my salescritter. What were they afraid of? Someone would trying to steal the design? Get real. It turns out there was a legitimate reason, though: the documentation of the instruction set is complete enough for people developing in-house, but far from the sort of thing that you'd want to hand out to Joe Average customer. Giving it out means support, which means training RTOC, training customers, and fixing bugs that block a customer's work but don't interfere with ours. There was also the opinion that the Pyramid, being a UNIX system, was not a machine people were supposed to be programming in assembler. And if anyone had suggested that a high-quality free C compiler would be floating around in 1988, you would have been laughed out of the room. Making the document "proprietary" and making the customer sign a non-disclo- sure was, amongst other things, a way of ensuring you know who had a copy of the silly thing. It would be interesting *now* to see if customers can put enough pressure on Pyramid to make the Architecture manual more available. Now that RISC-derived and really RISC designs are commonplace. <csg>
jpdres10@usl-pc.usl.edu (Green Eric Lee) (04/20/89)
In article <BOB.89Apr12152036@allosaur.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >I understand that it was done inside Pyramid, mostly as an exercise in >curiosity, and it worked fine. Last I heard, Pyramid was uninterested >in releasing it because it would reveal too much proprietary >information about their system. This "proprietary information" argument puzzles me. Anybody can look at the assembly-language output of "cc" on a Pyramid and figure out exactly how their "proprietary" assembly language works. I did it all the time when learning "C", to make sure that what I thought I was doing was what "cc" thought I was doing. 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. >Sounds like someone else outside Pyramid will have to go ahead and do >the work again. Yep. A pain. Reminds me of what someone once said about the Middle Ages: "Digitalis was invented at least four times that I know of. Each time, the secret died with its maker. That's the way things happened back then, you didn't share information." Are we headed towards a new Dark Ages? Well, if you measure that possibility by how many times we have to re-invent the wheel.... -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // {uunet!dalsqnt,killer}!usl!elg (318)989-9849 | | \X/ >> In Hell you need 4Mb to Multitask << |
wendyt@pyrps5 (Wendy Thrash) (05/05/89)
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.
scott@questar.QUESTAR.MN.ORG (Scott Anderson) (05/06/89)
In article <BOB.89Apr12152036@allosaur.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >I understand that it was done inside Pyramid, mostly as an exercise in >curiosity, and it worked fine. Last I heard, Pyramid was uninterested >in releasing it because it would reveal too much proprietary We have been using gcc and g++ on our 9815 and 98xe for a while now, and they do work fine. Most of the porting work for gcc (machine description) was done by jonathan@comp.vuw.ac.nz, and some other work was done here (g++) by us. -- Scott Anderson UUCP: scott@Questar.MN.ORG, Questar Data Systems ...!amdahl!bungia!questar!scott St. Paul, MN ATT: +1 612 688 0089