chuck@trantor.harris-atd.com (Chuck Musciano) (10/10/90)
I have been hearing a rumor (corroborated by two independent sources)
that DEC is readying a new RISC processor. Called either "Alpha" or
"Project Alpha", it is being developed in Oregon, and is yielding 100 MIPS.
Further, I hear that DEC is considering three choices:
1 Drop the project, and continue with their VAX/MIPS products.
2 Use Alpha to replace their MIPS workstations, porting Ultrix.
3 Use Alpha to replace their VAX machines, porting VMS.
While the urge to ruminate as to which of these choices is the fastest road
to corporate suicide is almost overwhelming, I will take the high road and
just ask the obvious:
What is Project Alpha?
What architectural features make it a win over SPARC or MIPS? Are they really
achieving 100 MIPS or more? What is the implementation technology? Does
anyone have any concrete information about this architecture?
--
Chuck Musciano ARPA : chuck@trantor.harris-atd.com
Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck
PO Box 37, MS 3A/1912 AT&T : (407) 727-6131
Melbourne, FL 32902 FAX : (407) 729-2537
A good newspaper is never good enough,
but a lousy newspaper is a joy forever. -- Garrison Keillorpelakh@mozart.convex.com (Boris Pelakh) (10/11/90)
I don't know much about this new processor, but option 3 - porting VMS to RISC seems to be highly unlikely, considering the fact that VMS heavily relies on the original VAX architecture with it's ultra-CISC style instruction set. Boris Pelakh "A day without sunshine is like a night" pelakh@convex.com -- Anon.
davecb@yunexus.YorkU.CA (David Collier-Brown) (10/11/90)
pelakh@mozart.convex.com (Boris Pelakh) writes: | I don't know much about this new processor, but option 3 - porting VMS to | RISC seems to be highly unlikely, considering the fact that VMS heavily | relies on the original VAX architecture with it's ultra-CISC style | instruction set. Er, I wouldn't describe the VAX as ultra-CISC. The existing vCISC architectures implement whole higher-level-language constructs as single instructions... one of the better examples is the old Honeywell EISbox, which did the basic constructs of COBOL and PL/1 in ``hardware''. That is not to comment on the research architectures, like the SWORD machine or the BBN C-machine. As to running VMS on a RISCy chip, it depends on the expansion factor when one maps (translates) VAX instructions into sequences of RISC instructions. It is simple to go the other way: Mips did so to simulate their earlier machines on a VAX. Going to a simpler architecture is a straightforward but **labourious** problem in optimal instruction-sequence selection, eactly what one slaves over to get a compiler to generate good code... The question reduces to ``do you expect to get good enough price-performance out of the result to justify the effort?''. --dave -- David Collier-Brown, | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave or just Willowdale, Ontario, | postmaster@{nexus.}yorku.ca CANADA. 416-223-8968 | work phone (416) 736-5257 x 22075
ken@dali.gatech.edu (Ken Seefried iii) (10/11/90)
In article <107038@convex.convex.com> pelakh@mozart.convex.com (Boris Pelakh) writes: >I don't know much about this new processor, but option 3 - porting VMS to RISC >seems to be highly unlikely, considering the fact that VMS heavily >relies on the >original VAX architecture with it's ultra-CISC style instruction set. I believe that DEC has already announced that it is deep into a project to port VMS to the MIPS machines. If I remember correctly, they expect to have something within two years. -- ken seefried iii ken@dali.gatech.edu "Vee haf veyz off making you talk...release da veasles..."
lm@slovax.Sun.COM (Larry McVoy) (10/11/90)
In article <107038@convex.convex.com> pelakh@mozart.convex.com (Boris Pelakh) writes: >I don't know much about this new processor, but option 3 - porting VMS to RISC >seems to be highly unlikely, considering the fact that VMS heavily >relies on the >original VAX architecture with it's ultra-CISC style instruction set. I heard that this chip had a fair bit of stuff that would allow it to emulate a VAX; both hardware and hooks for software. --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com
sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (10/12/90)
In article <15007@hydra.gatech.EDU>, ken@dali.gatech.edu (Ken Seefried iii) writes: >I believe that DEC has already announced that it is deep into a >project to port VMS to the MIPS machines. If I remember correctly, >they expect to have something within two years. Nooooo..DEC is porting to a "RISC" architecture. According to Digital Review, they have one more generation of pure-CISC chips to pump out for VAX machines, before they go to a hybred chip which is RISCy but runs the VMS command set. They are also working on a "portable" VMS written in C, but I'm not so sure if they are committed to port it to the MIPS machines. That would mean they would have difficulty selling VAX hardware, because the price/performance between VAX hardware and MIPS hardware is different by a factor of 2-3.
wayne@dsndata.uucp (Wayne Schlitt) (10/12/90)
In article <143627@sun.Eng.Sun.COM> lm@slovax.Sun.COM (Larry McVoy) writes: > In article <107038@convex.convex.com> pelakh@mozart.convex.com (Boris Pelakh) writes: > >I don't know much about this new processor, but option 3 - porting VMS to RISC > >seems to be highly unlikely, considering the fact that VMS heavily > >relies on the > >original VAX architecture with it's ultra-CISC style instruction set. > > I heard that this chip had a fair bit of stuff that would allow it to emulate > a VAX; both hardware and hooks for software. is this something like what HP did when they converted their HP3000 MPE systems to the RISC based HP-PA system? i know that HP has had a painful time converting to RISC, even though they started a long time ago. the first RISC boxes didnt appear for a long time and even then, they had a hard time getting the new fast CPU to run the old code as fast as the 2-3 year old computers they replaced. I hear that recompiling your code did wonders for your performance... fortunately for HP, most of the HP3000 shops didnt use assembler or languages that did incremental compiles. thinking about it, i guess IBM has done similar things with their S/34->S/36->S/38->AS/400 line of computers. it is my understanding that all of these computers actually had very different instruction sets, but because everyone used RPG, people could move to the other computers fairly easily... -wayne
henry@zoo.toronto.edu (Henry Spencer) (10/13/90)
In article <16034@yunexus.YorkU.CA> davecb@yunexus.YorkU.CA (David Collier-Brown) writes: > As to running VMS on a RISCy chip, it depends on the expansion factor when >one maps (translates) VAX instructions into sequences of RISC instructions. >It is simple to go the other way: Mips did so to simulate their earlier >machines on a VAX. Going to a simpler architecture is a straightforward but >**labourious** problem ... Unfortunately, there are a couple of big jokers in the deck whenever you are talking about emulating one machine on another. Actual instruction selection is not that big a deal. The big problems with the actual translation typically are condition codes and data formats. (Note that "data formats" includes things like stack frames -- do you really want your nice fast RISC to spend half its time emulating the VAX calling sequence?) When talking about kernel code, another big problem will be assumptions of atomic execution of instructions. It Is Rumored, to use a non-VMS example, that the NFS code Sun ships is full of assumptions that "i++" is an atomic operation, which is true on a single-processor 68k but not on most RISCs. -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry
bobw@beverage.Eng.Sun.COM (Robert Weiler) (10/13/90)
In article <0093E081.85D1F940@KING.ENG.UMD.EDU> sysmgr@KING.ENG.UMD.EDU (Doug Mohney) writes: {Dec maybe porting VMS to RISC...} >They are also working on a "portable" VMS written in C, but I'm not so sure >if they are committed to port it to the MIPS machines. That would mean they >would have difficulty selling VAX hardware, because the price/performance >between VAX hardware and MIPS hardware is different by a factor of 2-3. I have never quite understood this line of reasoning which, unfortunately, was also prevelant at my previous place of employment. People buy a lot of VAX/VMS machines *despite* the fact that the price performance is very poor compared to almost any UNIX/RISC box, even the ones sold by DEC. Therefore the obvious conclusion is that what these people are really buying is VMS and it is worth a lot of money to them. So the proper equation is $(MIPS box + VMS) == $(VAX + VMS) DEC should be very happy with this because the machine costs them the same amount to build whether it comes with VMS or UNIX, so all of the extra dollars are profit. Ask Bill Gates. :-) Of course, you lose binary compatibility, so until the third party catalog is ported (and it may never be), the system isn't really worth anything. And that's a hard problem to get around. bob. Disclaimer: I kind of doubt that Sun has an opinion about this, and even if they do, it is certainly unrelated to mine.
davecb@yunexus.YorkU.CA (David Collier-Brown) (10/13/90)
In the presence of a Henry, I made the ill-advised comment: [...] Going to a simpler architecture is a straightforward but | **labourious** problem ... henry@zoo.toronto.edu (Henry Spencer) replied: | Unfortunately, there are a couple of big jokers in the deck whenever you | are talking about emulating one machine on another. [...] | (Note that "data formats" includes things like stack frames -- do you | really want your nice fast RISC to spend half its time emulating the VAX | calling sequence?) I think I can claim that this is a large-scale instance of finding the right tranformations or right instructions. If it's stereotyped enough, it is succeptable to transformation, even though it's both large and pervasive. I may be pushing compiler technology fairly hard, though. Certainly I'm well past my state-of-practice. | When talking about kernel code, another big problem will | be assumptions of atomic execution of instructions. It Is Rumored, | to use a non-VMS example, that the NFS code Sun ships is full of | assumptions that "i++" is an atomic operation, which is true on a | single-processor 68k but not on most RISCs. And that one's a perfect stopper. If such a semantic for the construct is assumed by a kernel developer, we is in deep do-do. Even worse, we have to detect it (:-)). I expect the really good ``stoppers'' won't be found until after the first few versions of the transformed code go into test... A **real bad** time to go back to the compier-design gurus. --dave (chastened but unbowed) c-b -- David Collier-Brown, | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave or just Willowdale, Ontario, | postmaster@{nexus.}yorku.ca CANADA. 416-223-8968 | work phone (416) 736-5257 x 22075
henry@zoo.toronto.edu (Henry Spencer) (10/14/90)
In article <16138@yunexus.YorkU.CA> davecb@yunexus.YorkU.CA (David Collier-Brown) writes: >| (Note that "data formats" includes things like stack frames -- do you >| really want your nice fast RISC to spend half its time emulating the VAX >| calling sequence?) > > I think I can claim that this is a large-scale instance of finding > the right tranformations or right instructions. If it's stereotyped > enough, it is succeptable to transformation, even though it's both > large and pervasive... I'd call it pretty large scale, because you have to deal with all the code's hidden assumptions about data-structure layout if you want to revise the stack-frame design to speed up calls. It's in a different league from what I'd normally think of as instruction choice. >| [rumor] that the NFS code Sun ships is full of >| assumptions that "i++" is an atomic operation, which is true on a >| single-processor 68k but not on most RISCs. > > And that one's a perfect stopper. If such a semantic for the > construct is assumed by a kernel developer, we is in deep do-do... Indeed we is. People within Sun tell me that this particular problem (a) definitely did exist, but (b) has been fixed. Of course, the version Sun has internally, the version it has shipped to suppliers, the versions they are shipping to their customers, and the versions the customers are actually running are four often-different things, so I would not be surprised if this bug is still out in the field in bulk. I've also had various bits of mail about i++ atomicity and |= atomicity assumptions being found in i/o drivers and such during RISC development. The worst part of these bugs is that the interrupt window is very narrow, so they don't necessarily show up quickly. -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry
seanf@sco.COM (Sean Fagan) (10/14/90)
In article <143627@sun.Eng.Sun.COM> lm@sun.UUCP (Larry McVoy) writes: >I heard that this chip had a fair bit of stuff that would allow it to emulate >a VAX; both hardware and hooks for software. Well... pure speculation time. It should be possible to take the "most common instructions" and hardwire them. I mean instruction and operand types, that is. For example mov (rx), ry could be a valid single instruction (but a bit long, I will admit: 3 bytes, I believe). Then, you trap all "instructions" that you don't recognise; for example, you could trap mov @(_foobar), @(_barf) (Is that a valid VAX instruction? I don't have my reference here, and would probably never use such an instruction anyway 8-).) Depending on the instruction mix, this could result in a *very* fast processor. If you only handle certain operand mixes, you're dealing with (more or less) fix-lengthed instructions, so you can more easily pipeline the sucker. Anyway, just a thought. Others know more than I do, obviously 8-). -- -----------------+ Sean Eric Fagan | "*Never* knock on Death's door: ring the bell and seanf@sco.COM | run away! Death hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.
seanf@sco.COM (Sean Fagan) (10/15/90)
In article <1353@exodus.Eng.Sun.COM> bobw@beverage.Eng.Sun.COM (Robert Weiler) writes: >Of course, you lose binary compatibility, so until the third party >catalog is ported (and it may never be), the system isn't really >worth anything. And that's a hard problem to get around. I don't know if that's the case. Elxsi went to a great deal of trouble to be VMS compatable, at the user-interface and programmers' level (high-level languages, not assembly, of course 8-)), and, apparantly, they were quite good at it. Since Elxsi is (effectively) dead now, they may not be the greatest of examples, but they did make a VMS clone on a non-VAX, using no VMS source code... -- -----------------+ Sean Eric Fagan | "*Never* knock on Death's door: ring the bell and seanf@sco.COM | run away! Death hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.
Russell_Williams.design_women@gateway.qm.apple.com (Russell Williams) (10/16/90)
In article <8198@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes: > I don't know if that's the case. Elxsi went to a great deal of trouble to > be VMS compatable, at the user-interface and programmers' level (high-level > languages, not assembly, of course 8-)), and, apparantly, they were quite > good at it. Elxsi produced a good source-level emulation of perhaps the most common 20% of VMS functionality; that took care of most applications and was effective in convincing a very small percentage of VAX shops to buy the Elxsi hardware. Elxsi faced two limitations in producing VMS emulation: one was an engineering team of only 6-8 engineers trying to duplicate DEC's thousands of engineer-years of effort. The other was machine architecture. Elxsi had the advantage of a similar flat 32-bit memory model, and IEEE arithmetic which was similar to a couple of DEC's alphabet soup of floating point formats. These formats weren't identical though, and floating point applications often got slightly different results. These could be proven to be more accurate than the DEC results, but customers didn't like it anyway. The Elxsi is a consistent big-endian machine and no attempt was made to emulate the VAX's inside-out/little endian byte ordering. The expectations for a DEC "VMS compatible" system would be considerably higher. In most respects relevant to porting VMS application source, the Elxsi is similar to commercial RISC architectures (memory model, floating point data format, consistent endian-ness). The last two of these architectural features caused gaps in VMS emulation which Elxsi never bridged but which DEC could not ignore in a credibly "compatible" solution. Interpretation of VAX object code on a commercial RISC would probably produce terrible performance. The floating point format problems remain, and the VAX instruction set is not suitable for emulation on most commercial RISCs because of the byte-aligned nature of instructions. Object code translation would probably fare better, but data alignment and floating point format problems remain. I conclude that DEC would either design their own RISC platform or market a commercial RISC/VMS box with more limited compatibility and "porting aid" claims.