thuermel@ztivax.siemens.com (Dr Sabine Thuermel) (02/11/91)
A few days ago I read about PAX (parallel architecture extended) by Alliant. Is this really a combination of HW and SW features (i860+ concurrency control instruction set plus a Unix System V extension+ PHIGS+ automatic parallelization of Fortran and C)? Will it become a standard? If I get detailed information and if there enough interest I'll summerize to the net. __ Sabine Thuermel e-mail: thuermel@ztivax.siemens.com
apfiffer@admin.cse.ogi.edu (Andy Pfiffer) (02/12/91)
In article <13043@hubcap.clemson.edu> thuermel@ztivax.siemens.com (Dr Sabine Thuermel) writes: >A few days ago I read about PAX (parallel architecture extended) >by Alliant. >Is this really a combination of HW and SW features (i860+ concurrency >control instruction set plus a Unix System V extension+ PHIGS+ >automatic parallelization of Fortran and C)? Will it become a standard? My turn on the soapbox? Okay, these are just my opinions, but: I doubt that PAX will become a standard. A standard requires consensus both in the marketplace *and* with third party developers. A standard also implies full and timely disclosure to all interested parties. PAX currently has neither. And as far as *I* can tell, it is quite closely coupled to the i860, Alliant's hardware (and model of parallelism), and Alliant's compiler suite. Unless Alliant suddenly swamps the parallel systems market, PAX just won't make the big time. Anecdotal evidence: After 14 months of phones calls and lengthy, often heated, meetings with Intel sales reps, Intel politburo, the VP of i860 product marketing (Dick Pierce), and communications with Alliant, we were never able to extract more than marketing hype about PAX from Intel. We still don't know why. The meetings or phone calls went like this: Us: What can you tell us about PAX? We'd like to know. Intel: It's the greatest thing since sliced bread. Will your product support PAX? Us: We expect to be i860 ABI compliant, and we will consider PAX compatability as well. Our architecture and model of parallelism isn't like PAX, at least what we understand about it, but we could probably provide a compatibility library... We've received the marketing information; we need specifications and implementation details. We can't support PAX without knowing what it is and how it works. Intel: Well, *I* don't know that much about it, but we should be getting the spec soon. I can get you a press release. I'll check on the spec and get back to you. We were finally given the name and number of a person at Alliant that was "the provider of PAX information." That was unacceptable for us -- we hadn't announced any i860-based product and we didn't want to call a potential competitor and introduce ourselves. (We did manage to get put on a mailing list under an assumed name, however! :^) We did get a non-disclosure copy of a spec for a potential future Intel product from which we derived some low-level details hidden between the lines; hardly what I'd call a PAX specification. As of October 1990, the PAX spec was still in the hands of Alliant and they were the sole point of contact for technical information. That may have changed by now. There have been several Big Time screw-ups with the "productizing" of the i860 (the orphaning of the Star860 platform, the delays in System V R4, etc.), PAX is just one more fumble. Unless you've got a big Alliant with i860's, you'll be far more likely to see AIX/860, OS/2, NX, Minix, Mach 3.0, Trollius, Display Postscript, or X Windows server code running than PAX on parallel i860's. And those fumbles are a real shame; on a per square-inch of board space basis, the performance the i860 can potentially deliver is (was?) hard to beat. Mother Intel could learn a thing or two from MIPS about development platforms, support, compilers, and how to handle a small customer... It should be noted that the largest parallel i860 systems built to date (iPSC/860's and the Touchstone field prototype) don't currently support PAX. Okay, I'm done with the soapbox. Who's next? -- Andy Pfiffer (503) 645-1886 apfiffer@admin.ogi.edu Formerly w/ Cogent Research, Formerly w/ Topologix, Formerly w/ Theory Center. "To determine where to resume execution upon leaving the trap handler, examine the instruction at address fir - 4.