johnr@ogccse.ogc.edu (John Roberts) (04/16/89)
I'm interested in evaluation of the current crop of RISC processors based on some common criteria. Here's the list of RISC processors I know about (feel free to add more): AMD 29000 Intel i860 Motorola 88000 MIPS R3000 Sun/Cypress SPARC VLSI Technology VL86C010 Intergraph Clipper Here's the criteria I currently use: clock speed transister count on-chip floating point unit? (and/or MFlops of FPU) pipelined execution on-chip caches I'd be interested in what criteria other silicon-groupies use for evaluating CPUs (especially as it relates to RISC). John Roberts "hanging out at Cogent Research, Inc. and Oregon Graduate Center" johnr@ogccse.ogc.edu
schow@bnr-public.uucp (Stanley Chow) (04/18/89)
In article <2368@ogccse.ogc.edu> johnr@ogccse.ogc.edu (John Roberts) writes: >I'm interested in evaluation of the current crop of RISC processors based >on some common criteria. [...] > >Here's the criteria I currently use: > > clock speed > transister count > on-chip floating point unit? (and/or MFlops of FPU) > pipelined execution > on-chip caches My question is: Why this set of criteria? This looks more like an accessment of the semiconductor technology. You touch upon the architecture and implementation issues only peripherally. Would not MIPS, FLOPS, ?h*stones, ... be more useful? If you really have deep objections to the standard "trivial" benchmarks, devise your own. If you want to compare raw power, count FLOPS assuming maximal pipeline occupancy. BTW, do you consider a high clock speed to be good or bad? [This is a serious question. A 100MHz CPU chip will drag in a lot of design issues that most people would rather not face.] Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public (613) 763-2831 Oh, that article; I didn't say anything. I was parroting what other people was saying. How could it be my opinion if I don't even know what it means?
paul@moncam.co.uk (Paul Hudson) (04/20/89)
In article <596@eutrc3.UUCP>, rcbaps@eutrc3.UUCP (Pieter Schoenmakers) writes: > In article <2368@ogccse.ogc.edu> johnr@ogccse.ogc.edu (John Roberts) writes: > >I'm interested in evaluation of the current crop of RISC processors based > >on some common criteria. Here's the list of RISC processors I know about > >(feel free to add more): > > > >[...] > > VLSI Technology VL86C010 > >[...] > Just to mention my favourite CPU: The Acorn RISC Machine (ARM), aka VL86C010. > Data for the ARM-2 (Used in the Acorn Unix Workstation): Problems: Max 4Mb memory with current memory controller. 32 Kbytes page size. Poor 16 bit support (a problem with some peripherals). No DMA support. High-resolution screens steal a lot of bandwidth. No delayed branch. Goodies: Uses cheap memory well. Is v. cheap Nice instruction set (although few instructions, it's remarkablly flexible. Pre-increment by 17? Post-increment by 134? No problem. All maths ops are 3 operand, and one operand can be fed to a barrel shifter. This is a *big win*.). Conclusion. In the right application, unbeatable. Not my choice for a workstattion. Disclaimer: I used to work for Acorn, and have writtern (the back end of) a compiler for the beast. Thus the above may be disillusionmemnt. Paul Hudson Snail mail: Monotype ADG Email: ...!ukc!acorn!moncam!paul Science Park, paul@moncam.co.uk Milton Road, "Sun Microsysytems: Cambridge, The Company is Arrogant (TM)" CB4 4FQ
mkraiesk@midas.UUCP (Mark Kraieski) (04/21/89)
in article <2368@ogccse.ogc.edu>, johnr@ogccse.ogc.edu (John Roberts) says: > > I'm interested in evaluation of the current crop of RISC processors based > on some common criteria. Here's the list of RISC processors I know about > (feel free to add more): ... > > Here's the criteria I currently use: > > clock speed > transister count > on-chip floating point unit? (and/or MFlops of FPU) > pipelined execution > on-chip caches > > I'd be interested in what criteria other silicon-groupies use for evaluating > CPUs (especially as it relates to RISC). > > John Roberts > "hanging out at Cogent Research, Inc. and Oregon Graduate Center" > johnr@ogccse.ogc.edu There is another angle on the criteria that is just as important as your items and may be the deciding factor. I'm talking about software and market factors: Availability of O/S and compilers from multiple sources. Mature code generators. Standards (source, object, binary) and conformment. Committment to upward compatibility (family). Scalability. Existing software base and future growth. Reliability in meeting delivery dates. Multiple vendors supplying chip. Depending on what you plan on doing with the "hottest" RISC chip you can find, the above issues may be important if you plan on selling it. The above criteria can make a chip of lower performance more attractive. Mark Kraieski +-----+ \ | Gould, CSD (makers of fine computers) +------+ \ +----+ Micro Systems Develpoment, MS 404 | | \ | [ now owned 6901 West Sunrise Blvd. | | / | by Encore ] Ft. Lauderdale, FL 33313-4499 +------+ / +----+ / | (305) 587-2900 +-----+
rec@dg.dg.com (Robert Cousins) (04/24/89)
In article <1464@cfa.cfa.harvard.EDU> mkraiesk@midas.UUCP (Mark Kraieski) writes: >in article <2368@ogccse.ogc.edu>, johnr@ogccse.ogc.edu (John Roberts) says: >> >> I'm interested in evaluation of the current crop of RISC processors based >... >> >> Here's the criteria I currently use: >> >>... >> >> I'd be interested in what criteria other silicon-groupies use for evaluating >> CPUs (especially as it relates to RISC). >> >> John Roberts >> "hanging out at Cogent Research, Inc. and Oregon Graduate Center" >> johnr@ogccse.ogc.edu > >There is another angle on the criteria that is just as important as your >items and may be the deciding factor. I'm talking about software and >market factors: > > Availability of O/S and compilers from multiple sources. > Mature code generators. > Standards (source, object, binary) and conformment. > Committment to upward compatibility (family). > Scalability. > Existing software base and future growth. > Reliability in meeting delivery dates. > Multiple vendors supplying chip. > >Depending on what you plan on doing with the "hottest" RISC chip you can >find, the above issues may be important if you plan on selling it. The >above criteria can make a chip of lower performance more attractive. >Mark Kraieski Really, the criteria break down into several major catagories: 1. Will this RISC do my job today? Here is where the code generator and software base questions go. 2. Will this RISC do my job tomorrow? Here is where the multiple vendors and the scalability questions go. 3. Will I be left in the cold? Here is where the ABI questions go. Each of these criteria can be further simplified. The first question can be restated to be "Is there enough there to do my job now?" This is in many ways more important than the other questions since RISC support can take a long time to develop. The best example I know of is with compilers. Some RISC processors (such as MIPS) have extensively tuned compilers behind them. These compilers are extremely complex and designed to squeeze every bit of speed from them. However, other RISC processors (such as the 88000) with less complex compilers still beat the pants off of them. Therefore, it isn't the maturity of the code generator, it is the delivered bang/$. As for the second question, I know of no major RISC family which doesn't have either announced or unannounced follow-on products. Therefore, unless someone folds, there probably will be support for the next generation of products. Therefore, for now, the second question can almost (;-) be considered moot. The third question really boils down to "how do I know I won't make the wrong choice?" This one is tough. We made our choice for well publicised reasons. Other companies have made their choices for their own valid reasons. Who knows? I suspect that the market will boil down to two major CISCs (80x86 and 680x0) and two major RISCs (88K and either SPARC or MIPS). Robert Cousins Dept. Mgr, Workstation Dev't Speaking for myself alone.
mash@mips.COM (John Mashey) (04/26/89)
In article <141@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: .... >> Mature code generators. ... >> >....can take a long time to develop. The best example I know of is with >compilers. Some RISC processors (such as MIPS) have extensively tuned >compilers behind them. These compilers are extremely complex and designed >to squeeze every bit of speed from them. >However, other RISC processors (such as the 88000) with less complex >compilers still beat the pants off of them. Therefore, it isn't the ---------------------------------------^^^^ >maturity of the code generator, it is the delivered bang/$. The "them" was a little ambiguous: I assume it meant "CISC chips", not R3000s (as 3000s were the last "them" mentioned.) Note that "maturity" of code generators (and compiler technology) in general, is unfortunately even less well-defined than mips&mflops, and it's a lot more than generating good code. I once took a stab at a few verifiable metrics for compiler system "maturity". Here are a few quick samples: - can you mix and match different languages, like C, FORTRAN, Pascal? - can you source-debug them, too? - can you do the same with COBOL, PL/1, or ADA and the others? (much harder; here's where linkage conventions and/or symbol tables break) - compilation speeds - robust in face of huge programs? - can you compile and link (for example) a 1-2-million-line program that generates a single executable of 32MB of CODE? - can you debug it? - can you compile/link/debug a program that has a 1000 different include files? Hmmm. here's an interesting question for the net: how about offering examples of LARGE programs, either in: # of files # of lines of source # of bytes of code generated what machine & OS & language does this run on? what does it do? We've seen some real monsters land on our machines; maybe other people have good examples also. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
rec@dg.dg.com (Robert Cousins) (04/28/89)
In article <18120@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >Note that "maturity" of code generators (and compiler technology) in >general, is unfortunately even less well-defined than mips&mflops, >and it's a lot more than generating good code. Very true. The real question is suitability for real world tasks in today's (and tomorrow's) multivendor computing environment. >I once took a stab at a few verifiable metrics for compiler system >"maturity". Here are a few quick samples: >- can you mix and match different languages, like C, FORTRAN, Pascal? > - can you source-debug them, too? > - can you do the same with COBOL, PL/1, or ADA and the others? > (much harder; here's where linkage conventions and/or > symbol tables break) True. Many development systems do break here. This is unfortunately true of some of the best software development Unix platforms which have been extensively tailored for C or C/F77 at the expense of everything else. The real issue here is no so much one of compilers, however, but of the actual object code produced and used on a given system. The 88K OCS (Object compatibility standard) addresses most of these issues and is designed to provide extensibility so that future requirements can be met. And compilers from multiple companies can be intermixed -- even across the language spectrum. In fact, there is a standard 88K calling sequence which the ABI specifies which is supported by the various compilers. As has been amply pointed out, this is lacking elsewhere in the industry. Hopefully, the rest of the computing world will follow our lead to true interoperability. Robert Cousins Speaking for myself alone.
mash@mips.COM (John Mashey) (04/29/89)
In article <144@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: ..... >The real issue here is no so much one of compilers, however, but of >the actual object code produced and used on a given system. The 88K >OCS (Object compatibility standard) addresses most of these issues and >is designed to provide extensibility so that future requirements can >be met. And compilers from multiple companies can be intermixed -- >even across the language spectrum. In fact, there is a standard 88K >calling sequence which the ABI specifies which is supported by the >various compilers. As has been amply pointed out, this is lacking >elsewhere in the industry. Hopefully, the rest of the computing world >will follow our lead to true interoperability. Uh. Sorry, but there are standard calling sequences for both MIPS, and SPARC, at least, and have been for a quite a while, and they came into existence with the chips, or actually, well before chips existed. I guess I missed making the point originally, so let me try again. The point was that things like standard calling conventions and object formats are just the starting points. Then the work begins, and it takes years to really get the full act together, if you want to do: more than C & FORTRAN mixtures of languages big programs solid exception-handling debug the various combinations well, and efficiently In particular, regular COFF-like symbol tables don't quite make it. I took a look at the 88K BCS recently, and due to lack of time I didn't notice it, but I couldn't find things that specifically addressed issues that arise with Ada, PL/1, etc [which doesn't mean they're not there, just that I didn't see them]. Could you point me at the right places to look? From experience, I observe: 1) from when C works, it's a while until the others work. 2) From when an FPU is perfect, it can take a while until all of the FP libraries, exception-handling, etc, is really well wrung-out, because it takes running lots of real, large, heavy-duty FP code to track down the odd corners. [and remember, MIPS R2000s give precise exceptions for floating-point, which makes them one of the easier cases, in some sense...] 3) From when C works, it can take YEARS of work to make the harder combinations of all this be solid. [We're still certainly fixing and improving things, even though we could generate optimized code for C & Pascal in 1985.] Before claiming the lead in operability, I'd suggest that passing a couple milestones would help believability: 1) Production systems (including FP), in end-users' hands. 2) Any commercial Spice in end-user's hands (this is always a useful test for FORTRAN & FP in general). 3) ISV Compile, link, and debug (without programmers going crazy) something like (for example) million-line {PL/1 or FORTRAN, or Ada} programs mixed with C and assembler, and put the result in end-user production use. Anyway, this is not to knock the 88K BCS, which is a very reasonable effort, merely to observe that it's the first step on a road that's longer, and twistier than you might think.... -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
rec@dg.dg.com (Robert Cousins) (05/01/89)
In article <18316@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >In article <144@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >..... >>The real issue here is no so much one of compilers, however, but of >>the actual object code produced and used on a given system. The 88K >>OCS (Object compatibility standard) addresses most of these issues and >>is designed to provide extensibility so that future requirements can >>be met. And compilers from multiple companies can be intermixed -- >>even across the language spectrum. > >Uh. Sorry, but there are standard calling sequences for both MIPS, and SPARC, >at least, and have been for a quite a while, and they came into existence >with the chips, or actually, well before chips existed. Last time I heard, there were few if any third party compilers for MIPS which gives you the ability to totally control the interoperability of languages. >The point was that things like standard calling conventions and object >formats are just the starting points. Agreed. The calling sequence is just the beginning. You also need symbol management, data structure format and alignment standards, OS interface standards, side effect definitions and many other things so that all vendors can take advantage of the entire environment. >Then the work begins, and it takes >years to really get the full act together, if you want to do: > more than C & FORTRAN > mixtures of languages > big programs > solid exception-handling > debug the various combinations well, and efficiently Actually, not quite. If these features are being retrofitted into a system, yes, it can take a long time. If, however, the plan is to support these from the outset, the learning curve is not so steep. >I took a look at the 88K BCS recently, and due to lack of time I didn't >notice it, but I couldn't find things that specifically addressed issues that >arise with Ada, PL/1, etc [which doesn't mean they're not there, just that >I didn't see them]. Could you point me at the right places to look? The OCS is a seperate document with specific hooks for Ada, PL/I, etc. It deals with not only the extended/nested symbol table issues but also attempts to deal with the other known problems as mentioned by all of the 88/Open members. The collective experience and knowledge of the 88/Open group is substantial. >From experience, I observe: > 1) from when C works, it's a while until the others work. Yes, this difficulty is common, if you are not specifically driving for multilanguage interoperability from the beginning (which was not done on early CISC processors either). > 2) From when an FPU is perfect, it can take a while until all of > the FP libraries, exception-handling, etc, is really well wrung-out, > because it takes running lots of real, large, heavy-duty FP code > to track down the odd corners. Actually, this difficulty arises only if you have just one company doing the compilers. > 3) From when C works, it can take YEARS of work to make the harder > combinations of all this be solid. [We're still certainly fixing and > improving things, even though we could generate optimized code > for C & Pascal in 1985.] Again, it takes this long to shake out the bugs ONLY when you have just one company writing the software. I'm sure you would agree that (at the beginning) there was only one small group writing compilers for the MIPS processor. In the Sparc and 88K worlds, multiple companies worked on compilers from day one. I believe that it is clear, that this competitive situation, with a published standard as reference, has resulted in excellent compilers, very quickly. Note that compilers for the 88K produce code RIGHT NOW with performance (Mhz for Mhz) equal to the MIPS compiler, which has been in development for years. >Anyway, this is not to knock the 88K BCS, which is a very reasonable effort, >merely to observe that it's the first step on a road that's longer, and twistier >than you might think.... >-- >-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> Actually, it is difficult to unilaterally solve all of the problems in interoperability. However, when a group of motivated experts from numerous companies sit down to solve the problems, it is amazing the progress which can be made. The 88K world is amazingly unified in its desire to ensure that programming the 88K remains an easy task and to this end, the entire 88/Open world is carefully working to guarantee interoperability with not only their own products, but everyone else's. Robert Cousins Dept. Mgr, Workstation Dev't Speaking for myself alone.
len@synthesis.Synthesis.COM (Len Lattanzi) (05/02/89)
In article <147@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: :In article <18316@winchester.mips.COM> mash@mips.COM (John Mashey) writes: :>In article <144@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: :>..... :>>be met. And compilers from multiple companies can be intermixed -- :>>even across the language spectrum. :> :>Uh. Sorry, but there are standard calling sequences for both MIPS, and SPARC, :>at least, and have been for a quite a while, and they came into existence :>with the chips, or actually, well before chips existed. : :Last time I heard, there were few if any third party compilers for MIPS :which gives you the ability to totally control the interoperability of :languages. I hope all your third party compilers support the same command line functions and functionality. One of the nice things about have a core set of compilers on the mips chip is that system("cc/as/ld") works regardless of where I'm running on a MIPS, SGI 4D or DECstation. The Micro Focus Cobol Compiler uses the MIPS calling sequence defined in Kane's MIPS R2000 book and C/Cobol call each other with ease. : :>The point was that things like standard calling conventions and object :>formats are just the starting points. : :Agreed. The calling sequence is just the beginning. You also need :symbol management, data structure format and alignment standards, OS :interface standards, side effect definitions and many other things so :that all vendors can take advantage of the entire environment. : :>Then the work begins, and it takes :>years to really get the full act together, if you want to do: :> more than C & FORTRAN :> mixtures of languages :> big programs :> solid exception-handling :> debug the various combinations well, and efficiently : :Actually, not quite. If these features are being retrofitted into :a system, yes, it can take a long time. If, however, the plan is :to support these from the outset, the learning curve is not so steep. : :>I took a look at the 88K BCS recently, and due to lack of time I didn't :>notice it, but I couldn't find things that specifically addressed issues that :>arise with Ada, PL/1, etc [which doesn't mean they're not there, just that :>I didn't see them]. Could you point me at the right places to look? : :The OCS is a seperate document with specific hooks for Ada, PL/I, etc. :It deals with not only the extended/nested symbol table issues but also :attempts to deal with the other known problems as mentioned by all of the :88/Open members. The collective experience and knowledge of the 88/Open :group is substantial. : :>From experience, I observe: :> 1) from when C works, it's a while until the others work. : :Yes, this difficulty is common, if you are not specifically driving for :multilanguage interoperability from the beginning (which was not done on :early CISC processors either). : :> 2) From when an FPU is perfect, it can take a while until all of :> the FP libraries, exception-handling, etc, is really well wrung-out, :> because it takes running lots of real, large, heavy-duty FP code :> to track down the odd corners. : :Actually, this difficulty arises only if you have just one company doing :the compilers. You say tomato, I say... We'll have to see if Survival of the fittest 3rd party compiler will produce better results than a compiler group that is part of the design process at Mips. Whose 3rd party OS is available for the AViion? : :> 3) From when C works, it can take YEARS of work to make the harder :> combinations of all this be solid. [We're still certainly fixing and :> improving things, even though we could generate optimized code :> for C & Pascal in 1985.] : :Again, it takes this long to shake out the bugs ONLY when you have just :one company writing the software. I'm sure you would agree that (at :the beginning) there was only one small group writing compilers for the :MIPS processor. In the Sparc and 88K worlds, multiple companies worked :on compilers from day one. I believe that it is clear, that this :competitive situation, with a published standard as reference, has resulted :in excellent compilers, very quickly. Note that compilers for the 88K :produce code RIGHT NOW with performance (Mhz for Mhz) equal to the MIPS :compiler, which has been in development for years. : Care to quote FORTRAN performance numbers? :>Anyway, this is not to knock the 88K BCS, which is a very reasonable effort, :>merely to observe that it's the first step on a road that's longer, and twistier :>than you might think.... :>-- :>-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> : :Actually, it is difficult to unilaterally solve all of the problems in :interoperability. However, when a group of motivated experts from :numerous companies sit down to solve the problems, it is amazing the :progress which can be made. The 88K world is amazingly unified in its :desire to ensure that programming the 88K remains an easy task and to :this end, the entire 88/Open world is carefully working to guarantee :interoperability with not only their own products, but everyone else's. : :Robert Cousins :Dept. Mgr, Workstation Dev't : :Speaking for myself alone. Len Lattanzi (len@Synthesis.com) <{ames,pyramid,decwrl}!mips!synthesis!len> Synthesis Software Solutions, Inc. The RISC Software Company I would have put a disclaimer here but I already posted the article.
mash@mips.COM (John Mashey) (05/02/89)
In article <147@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: ..... >Actually, not quite. If these features are being retrofitted into >a system, yes, it can take a long time. If, however, the plan is >to support these from the outset, the learning curve is not so steep. Yep, I guess we msut have been dumb, as we planned for this stuff from day 1, and it still took us a while...:-) > >The OCS is a seperate document with specific hooks for Ada, PL/I, etc. >It deals with not only the extended/nested symbol table issues but also >attempts to deal with the other known problems as mentioned by all of the >88/Open members. The collective experience and knowledge of the 88/Open >group is substantial. Is this a published document? > >on compilers from day one. I believe that it is clear, that this >competitive situation, with a published standard as reference, has resulted >in excellent compilers, very quickly. Note that compilers for the 88K >produce code RIGHT NOW with performance (Mhz for Mhz) equal to the MIPS -----------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >compiler, which has been in development for years. The statement above is a) clear, b) definite, and c) VERY strong. Unlike much of the rest of the discussion (process X is better than process Y for getting compilers), this statement is at least testable. How about publishing some DATA to back this up? 1) Realistic integer programs would be good. (If Dhrystone is cited instead, at least show us the strcpy part so we know ifthe GreenHills strcpy inliner is being used.) 2) Realistic floating point programs would be of particular interest..... it will be interesting, for example, to see if the Spice or Doduc numbers from a 20MHz 88K beat a 16.7MHz M/120, or RC2030, or DECstation 3100, for example.... -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
jek3@lowpost.Sun.COM (Joseph Kowalski) (05/03/89)
In article <18653@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >In article <147@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >..... >> Note that compilers for the 88K >>produce code RIGHT NOW with performance (Mhz for Mhz) equal to the MIPS >-----------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>compiler, which has been in development for years. I fail to see the preoccupation with 'Mhz for Mhz'. I certainly would like to believe that one can design a simple state machine (like a D flip-flop) to run at a higher clockrate than a DSP or CPU chip (like 88K or R3000). If an architect chooses to implement an instruction set to aid compiler designers/performance at the expense of clockrate, that's his design decision. I certainly don't want to see 33 Mhz 88K compared against an R2000 at 8 Mhz (or other sadism), but I feel that the following is a much more meaningful comparison than 'Mhz for Mhz': Compare performance on the highest performing currently available implementation of an architecture in a given technology I realize that 'Mhz for Mhz' has more meaning in the RISC, ONE INSTRUCTION PER CLOCK world than in the CISC world, but even this is doubtful. Joe Kowalski (No fancy signature - My opinions are obviously my own - I tried, but I couldn't give them away!)
rec@dg.dg.com (Robert Cousins) (05/03/89)
In article <18645@mips.mips.COM> len@synthesis.synthesis.com (Len Lattanzi) writes: >In article <147@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >:Last time I heard, there were few if any third party compilers for MIPS >:which gives you the ability to totally control the interoperability of >:languages. >I hope all your third party compilers support the same command line functions >and functionality. . . . While I have no control over the command line options, it is interesting to notice how the most commonly used toggles such as "s," "o," "O," and "c" are almost universal. However, I view it as more important to be able to move the COMPILER I prefer between machines than to hope that the compiler on the other machine is similar to my favorite. This is what the ABI/BCS effort is all about. >The Micro Focus Cobol Compiler >uses the MIPS calling sequence defined in Kane's MIPS R2000 book and C/Cobol >call each other with ease. My point exactly. I assume that Micro Focus will be following the BCS while porting to the 88K. >:The 88/Open OCS is a seperate document with specific hooks for Ada, PL/I, etc. >:It deals with not only the extended/nested symbol table issues but also >:attempts to deal with the other known problems as mentioned by all of the >:88/Open members. The collective experience and knowledge of the 88/Open >:group is substantial. >: >:Actually, this difficulty arises only if you have just one company doing >:the compilers. > >You say tomato, I say... >We'll have to see if Survival of the fittest 3rd party compiler will produce >better results than a compiler group that is part of the design process at >Mips. In just the C compiler area, there are numerous heavy weight companies working for the 88K: LPI, Oasys/Greenhills, Diab, Translations Systems and others. Based upon these companies' technology, I think that some excellent compilers will be developed soon. The current crop seems to be doing well if you read last month's MIPS magazine. I understand that MIPS has purchased some compiler technology from at least one member of the above list. > Whose 3rd party OS is available for the AViion? I can't comment on this until the other vendors make their announcments. DG is pleased and proud of DG/UX and the reception that DG/UX is getting throughout the 88K world now that it is available for licensure by other members of the consortium. >Care to quote FORTRAN performance numbers? Any numbers you desire are available in the MIPS performance brief. When making comparisons, don't forget that AViiON goes for $7995 and runs at 16.67 Mhz. (It is really easy to compare this machine with others costing 5 times as much.) > > Len Lattanzi (len@Synthesis.com) <{ames,pyramid,decwrl}!mips!synthesis!len> > Synthesis Software Solutions, Inc. The RISC Software Company >I would have put a disclaimer here but I already posted the article. Robert Cousins Speaking for myself alone.
rec@dg.dg.com (Robert Cousins) (05/03/89)
In article <18653@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >In article <147@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >..... > >>The OCS is a seperate document with specific hooks for Ada, PL/I, etc. >>It deals with not only the extended/nested symbol table issues but also >>attempts to deal with the other known problems as mentioned by all of the >>88/Open members. The collective experience and knowledge of the 88/Open >>group is substantial. >Is this a published document? Yes, contact Anne Marie Larking at Motorola (512)891-3160 for the latest draft. >>on compilers from day one. I believe that it is clear, that this >>competitive situation, with a published standard as reference, has resulted >>in excellent compilers, very quickly. Note that compilers for the 88K >>produce code RIGHT NOW with performance (Mhz for Mhz) equal to the MIPS >-----------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>compiler, which has been in development for years. > >The statement above is a) clear, b) definite, and c) VERY strong. >Unlike much of the rest of the discussion (process X is better than >process Y for getting compilers), this statement is at least testable. > >How about publishing some DATA to back this up? Read MIPS magazine from April where the 88K went head to head with the 3100 and won based upon their full set of benchmarks. MIPS plans to follow up on this with detailed information in another article. We can banter back and forth about what are reasonable measures and what aren't but the bottom line is that an independent and objective organization with a good reputation has compared the two products and has published results which agree with my statement above. (And those benchmarks were run with a compiler now outdated.) Just as benchmarks are used between hardware manufacturers, they are used between compiler vendors. Universally, the losing compiler vendors claim some optimization is "unfair" and then usually adopt it in the next pass. Who wins? The consumer. Who loses? The bad compiler vendor. So, I reiterate my point: compilers produced in a competitive environment will mould their features and performance to the needs of the consumers. For those people who want fast compiles, there will probably be some company which can compile code at very high speeds (and potentially produce poor code). For those who desire the last ounce of performance there will be yet a different product. Lastly for those who want to minimize space there may be a third. There are already several good C compilers for the 88K and this number will only grow over the next years. >-- >-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> Robert Cousins Speaking for myself alone.
mpogue@dg.dg.com (Mike Pogue) (05/03/89)
In article <102441@sun.Eng.Sun.COM> jek3@sun.UUCP (Joseph Kowalski) writes: >R2000 at 8 Mhz (or other sadism), but I feel that the following is a much >more meaningful comparison than 'Mhz for Mhz': > > Compare performance on the highest performing currently available > implementation of an architecture in a given technology > >I realize that 'Mhz for Mhz' has more meaning in the RISC, ONE INSTRUCTION PER >CLOCK world than in the CISC world, but even this is doubtful. > Over time, MIPS, SPARC, and the 88K will all have pretty much the same clock rates, and will use the same feature sizes. When we decided to go RISC, we evaluated all three of these technologies, and finally decided that they were pretty similar architecturally. The 88K had better multiprocessor hooks, but that was a relatively minor consideration. THe bottom line was: who has the best chance of succeeding in the long run? A small company like MIPS, a company that can't decide whether it wants to sell chips or not (SPARC), or a big company that has succeeded once before (with the 68K series) that knows the business (MOTOROLA)? For us, it was pretty simple. If you compare performance on a weekly basis, you will find yourself flipping between vendors. What our customers have been asking for is a solid RISC, spanning a wide range of systems, supported by a solid chip vendor, and a company that knows how to build a wide range of systems (not just point products). Architecturally, you HAVE to compare Mhz for Mhz, or you are not looking at architecture. Mike Pogue Data General Corp. These opinions are my own....
rec@dg.dg.com (Robert Cousins) (05/03/89)
In article <102441@sun.Eng.Sun.COM> jek3@sun.UUCP (Joseph Kowalski) writes: >In article <18653@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >>In article <147@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >>..... >>> Note that compilers for the 88K >>>produce code RIGHT NOW with performance (Mhz for Mhz) equal to the MIPS >>-----------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>compiler, which has been in development for years. > >I fail to see the preoccupation with 'Mhz for Mhz'. I certainly would like >to believe that one can design a simple state machine (like a D flip-flop) >to run at a higher clockrate than a DSP or CPU chip (like 88K or R3000). >If an architect chooses to implement an instruction set to aid compiler >designers/performance at the expense of clockrate, that's his design >decision. I certainly don't want to see 33 Mhz 88K compared against an >R2000 at 8 Mhz (or other sadism), but I feel that the following is a much >more meaningful comparison than 'Mhz for Mhz': > > Compare performance on the highest performing currently available > implementation of an architecture in a given technology > >I realize that 'Mhz for Mhz' has more meaning in the RISC, ONE INSTRUCTION PER >CLOCK world than in the CISC world, but even this is doubtful. > >Joe Kowalski (No fancy signature - My opinions are obviously my own - I tried, > but I couldn't give them away!) Your point is well taken. By saying "Mhz for Mhz," I was attempting to make sure that reasonable machines are being compared. There is a penchant in this world for people to compare 25 Mhz MIPS machines with 16 Mhz 88Ks. Another way to put it is to compare machines dollar for dollar. It is not suprising that a $40K machine should compare well in performance to a machine selling for under $10K. We can talk $/Dhrystone MIP. We can talk $/Mhz or we can flat out match high end to high end. However, each of these has its disadvantages. Dollar for dollar comparisons don't apply when there is no overlap between the machines. For example, comparing a Cray with a PC. :-) High end to high end suffers from the same problem: one person's high end is another person's low end. This is especially true in the 88K world where a limited number of products are currently announced. If you want to base this upon announments of planned products, then the world changes again. It was stated at the AViiON announcement that there will be a 500 MIPS quad ECL 88K product. Should this be brought into the current discussion? Probably not. Low end to low end is somewhat more fair. In this space, the design goals are more similar and therefore it is often easier to make a direct comparison. However, the Cray vs PC problem still applies. $/MIP is the most fair since it more readily allows people to judge in an apples-for-apples equation. When one looks at a machine it should be possible to measure value (at least for a known group of problems) in relation to this. Comments? Robert Cousins Speaking for myself alone.
khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) (05/04/89)
In article <156@dg.dg.com> mpogue@dg.UUCP (Mike Pogue) writes: >> > Over time, MIPS, SPARC, and the 88K will all have pretty much the same >clock rates, and will use the same feature sizes. maybe, maybe not. If Prisma meets their schedules you will be proved wrong around Jan 1990. > company that can't decide whether it wants to sell >chips or not (SPARC).... Sun doesn't even bulid chips. The announced, and sucessfully executed (last 2 years), plan is to license (anybody who wants to get in the act) the technolgy and let them sell chips. One can debate the merits of the plan; but to characterize it as confused seems a bit much. Cheers. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (05/04/89)
In article <157@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >In article <102441@sun.Eng.Sun.COM> jek3@sun.UUCP (Joseph Kowalski) writes: >>In article <18653@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >>>In article <147@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >>>>produce code RIGHT NOW with performance (Mhz for Mhz) equal to the MIPS >Your point is well taken. By saying "Mhz for Mhz," I was attempting to make >sure that reasonable machines are being compared. There is a penchant in >Dollar for dollar comparisons don't apply when there is no overlap Dollar for dollar comparisons are really the result of, not the input to, the architectural question. It depends too much on financial and marketing considerations of the companies involved. Know any companies which have deliberately held back technology to avoid affecting current products? >High end to high end suffers from the same problem: one person's high Actually, with a given technology this isn't too bad. If you know that the technology is the high end, that is, and not affected by marketing, as above >Low end to low end is somewhat more fair. In this space, the design >$/MIP is the most fair since it more readily allows people to judge Marketing affects this too much again... Since this originally started as a discussion of a few "RISC" architectures implemented in very similar technology, it seems to ME that "Mhz for Mhz" isn't too bad a place to start. How about a discussion of what instructions get generated in the critical sections of your most favorite 5 benchmarks, and why the branch strategy, address generation strategy, procedure call strategy, and other relevant design choices end up producing fewer comparable instruction cycles. If you want to get into implementation issues, are there architectural reasons why EVERYBODY can't do f.p. adds in two cycles? Favorite benchmarks: I like LINPACK to start: if you don't have the f.p. and memory performance for good performance here, you can't solve my favorite problems. Some version of SPICE: a very commonly used code which is good for demonstrating branch and memory latency slowness. ... Pick your favorites and do the comparisons, and show why performance is, MHz for MHz, as good as MIPS. Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
jwest@pitstop.West.Sun.COM (Jeremy West) (05/05/89)
In article <156@dg.dg.com>, mpogue@dg.dg.com (Mike Pogue) writes: > In article <102441@sun.Eng.Sun.COM> jek3@sun.UUCP (Joseph Kowalski) writes: > >R2000 at 8 Mhz (or other sadism), but I feel that the following is a much > >more meaningful comparison than 'Mhz for Mhz': > > > > Compare performance on the highest performing currently available > > implementation of an architecture in a given technology In the real world the main thing to optimise is price/performance so we should be looking at what MIPS/MFLOPS can be achieved within a given development timescale, development budget and unit cost. Thats fine for embedded controllers but for Unix boxes there is also the issue of applications software. SPARC has over 500 applications, increasing at a very high rate. What do the other vendors claim? Sun claims that SPARC has more applications software than all other RISC systems put together in a recent SPARCware glossy. > Over time, MIPS, SPARC, and the 88K will all have pretty much the same > clock rates, and will use the same feature sizes. Given the same development resources and the same types of implementation that might be true. Right now there are more design teams working on more different future SPARC implementations because it is licensed to TI, Fujitsu, Cypress/Ross Technology, LSI, Prisma, Solbourne etc. The 88K only has Motorola and MIPS do all the chip designs themselves. I think that the competition between SPARC vendors to have the best performance will encourage more innovative developments. Right now Cypress has 40 MHz SPARC available, MIPS are at 25 MHz? 88K at 20 MHz? > When we decided to go RISC, we evaluated all three of these technologies, > and finally decided that they were pretty similar architecturally. The 88K > had better multiprocessor hooks, but that was a relatively minor > consideration. For a really nice multiprocessor implementation check out the Cypress CY7C605 Multiprocessor Cache/MMU (CMU-MP). It is designed by the people who left the Motorola 88K design team to set up Ross Technology. Cypress gave a series of seminars earlier this year and there is a good description in their RISC seminar notebook. > Architecturally, you HAVE to compare Mhz for Mhz, or you are not looking at > architecture. It depends how you define architecture. For SPARC the architecture is basically limited to the instruction set and registers. The user level instructions are a fixed part of the SPARC ABI and implementation variations are handled by the kernel. In fact the number of cycles taken to execute an instruction is not part of the architecture and varies between SPARC implementations. For example floating point instructions are despatched in two cycles on a Fujitsu SPARC chip and in one cycle on a Cypress SPARC chip. All this makes MHz to MHz comparisons an *implementation* comparison not an architecture comparison. > Mike Pogue > Data General Corp. Adrian Cockcroft std.disclaimer: these are my personal opinions. Sun Cambridge UK TSE sun!sunuk!acockcroft (Borrowing Jerry West's account at Mountain View to get at USENET)
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (05/05/89)
This should really be in e-mail, but it's bounced back faster than a superball. I'm thinking of getting a workstation, primarily for scientific computation. I was thinking originally of the NeXT machine, but it seems like there are better things coming out, especially for hard-core floating point performance. Right now for my thesis, I've been spoiled by using a Personal Iris workstation, which for my application, is twice as fast as a VAX 8700, and slightly faster than a Convex C120, even when fully vectorized. The Iris is out of my price range ($20K+), but I really don't need all the fancy color graphics. What I want is something like a NeXT: monochrome screen, medium-sized disk (~100 MB), and appropriate amount of memory(8 mb I guess). How does floating point compare to a DEC 3100? Price? I'm probably going to have to go for the lowest end machine. For the vendors: What would be the price on a DG workstation as described above, with and without educational discount? What kind of system software does it come with? Is it BSD or SYSV based? (which is it _really_?) Is X windows included? (i.e. a working, compatible server) How close is the OS to common "industry standards"? Is it possible for individuals to purchase, or can it only work through a department/purchasing officer? Can one get third-party memory or disk drives, e.g. do Macintosh RAM modules and SCSI drives work with it? For the users who have one: What's it like? Does it work as advertised? How much did you really have to pay? Much thanks, Matt Kennel mbkennel@phoenix.princeton.edu
rec@dg.dg.com (Robert Cousins) (05/05/89)
In article <24953@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >In article <157@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >>Your point is well taken. By saying "Mhz for Mhz," I was attempting to make >>sure that reasonable machines are being compared. There is a penchant in >>Dollar for dollar comparisons don't apply when there is no overlap >Dollar for dollar comparisons are really the result of, not the input to, >the architectural question. I disagree. If one plans to build a high end product, the architecture can include more features. If one plans a low end product, the features must be more utilitarian and priority based. We wanted to deliver a product with high-end CPU power at low end prices. This means that we were forced to carefully scrutinize each feature and component to get the maximum bang per buck. >It depends too much on financial and marketing >considerations of the companies involved. Know any companies which have >deliberately held back technology to avoid affecting current products? I can name one which hasn't done it with its latest 88K workstation. . . . >>High end to high end suffers from the same problem: one person's high >Actually, with a given technology this isn't too bad. If you know that the >technology is the high end, that is, and not affected by marketing, as above >>Low end to low end is somewhat more fair. In this space, the design >>$/MIP is the most fair since it more readily allows people to judge >Marketing affects this too much again... Marketing has a limited ability to influence these ratios. However, there are very few workstations which are able to ship for $500/MIPS. There aren't even any close which I am aware of. Sure marketing may be able to sway the pricing by 10% either way, but not 50% or 100%. What this whole thing boils down to is the quality of the underlying technology and its architectural implementation. >If you want to get into implementation issues, are there architectural reasons >why EVERYBODY can't do f.p. adds in two cycles? While this is a reasonable question (and suitable for further discussion here), there is a more basic question: What architectures enforce a given latency upon their instructions. Some RISC processors work without interlocks or scoreboarding so that the compilers are required to keep track of instructionlatency. This means that if the instruction latency changes, all software must be recompiled! (Sounds like the stone ages to me.) > Hugh LaMaster, m/s 233-9, UUCP ames!lamaster > NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov > Moffett Field, CA 94035 > Phone: (415)694-6117 Robert Cousins Dept. Mgr, Workstation Dev't. Data General Corp. Speaking for myself alone.
mpogue@dg.dg.com (Mike Pogue) (05/05/89)
In article <102927@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Languages Marketing -- MTS) writes: >maybe, maybe not. If Prisma meets their schedules you will be proved >wrong around Jan 1990. > My point is that a GaAs implementation cannot be compared ARCHITECTURALLY against a CMOS implementation. We are comparing architectures here, and the MIPS, 88K, and SPARC architectures are all pretty similar, given the same technology (implementation). We are, as has been announced, working on high speed ECL implementations of the 88K, and it would probably be wise to assume that a GaAs implementation is being worked on somewhere, too (its probably wise to assume that EVERYONE is working on GaAs). You can't compare a CMOS anything against a GaAs anything, and expect to make sense. Its apples and oranges! Let's look at architecture, folks, not implementation! Each architecture has its pluses and minuses, but the facts show that they are all pretty much the same on the major points: Heavily pipelined Large number of registers Smart Compilers On the lesser (but still important) points: Multiprocessor support (88K wins) Register scoreboarding (88K wins) Register Windows (debatable whether this is a win for SPARC or not) DM Cache (MIPS wins on performance, but not on price) Mike Pogue Data General Corp My opinions are my own....
mpogue@dg.dg.com (Mike Pogue) (05/05/89)
Some interesting points. However, Sun (of all the vendors) has the BIGGEST problem with vendor-to-vendor compatibility. Yes, Sun went to multiple vendors, but MIPS and the 88K can guarantee a much better compatibility story, because they don't have (for example) three DIFFERENT implementations of multiprocessing. And when latency changes on a Functional Unit (like floating point) in the future, the 88K register scoreboarding will allow performance increases WITHOUT CHANGING THE BINARY. Sun networks ALREADY have a massive problem with Sun/3 and Sun/4 binaries required for everything you use. Neither MIPS nor the 88K have this problem. Mike Pogue Data General Corp My opinions are my own....
guy@auspex.auspex.com (Guy Harris) (05/06/89)
> Sun networks ALREADY have a massive problem with Sun/3 and Sun/4 >binaries required for everything you use. Neither MIPS nor the 88K >have this problem. Which problem is that? SPARC, MIPS, and the 88K *all* have the problem that they don't run 68K binaries without some object-to-object compiler or interpreter, if that's the "massive problem with Sun/3 and Sun/4 binaries" to which you're referring. They probably all have the same problem of sharing with binary data files, unless they took the approach of having their compilers do 68K-style structure alignments (as I remember hearing Apollo's PRISM compiler does by default). Those are the only two "massive problem(s) with Sun/3 and Sun/4 binaries" I can think of.... All SPARC-based machines out now can run one another's user-mode binaries (as long as they don't do things like depend on fine details of address space layout, or assume some specific page size, or depend on kernel data structures, or depend on particular devices being present, or... you get the picture; these are, by and large, potentially problems for *any* chip). I presume this will continue to be true.
ram@shukra.Sun.COM (Renu Raman) (05/07/89)
In article <164@dg.dg.com> uunet!dg!mpogue (Mike Pogue) writes: > > Multiprocessor support (88K wins) > Register scoreboarding (88K wins) Could you be more specific here? i.e. what specific mp features that make 88k shine over the rest and what is so magic about register scoreboarding? I don't know the 88k arch. too well. >Mike Pogue >Data General Corp
les@unicads.UUCP (Les Milash) (05/08/89)
In article <165@dg.dg.com> mpogue@dg.UUCP (Mike Pogue) writes: > > Some interesting points. However, Sun (of all the vendors) has >the BIGGEST problem with vendor-to-vendor compatibility. i'm not sure; they get a markup on all those disks we bought to hold all those binaries :) :)... on the other hand the sun 3's think sparc executables are scripts, and blow chunks when they try to run them. this has always amazed me, considering how together sun sw is in most other respects. actually i must say that i love this network of suns; it's as de luxe a pile of hardware as i've ever used. >My opinions are my own.... my comments are just a snotty retort, not even an opinion.
khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) (05/16/89)
In article <165@dg.dg.com> mpogue@dg.UUCP (Mike Pogue) writes: > > Some interesting points. However, Sun (of all the vendors) has >the BIGGEST problem with vendor-to-vendor compatibility. > > Yes, Sun went to multiple vendors, but MIPS and the 88K can >guarantee a much better compatibility story, because they don't >have (for example) three DIFFERENT implementations of multiprocessing. ???? So far (as best I can tell) Sun has the most experience in this particular area. Multiple FPU's (two weitek's and a TI), third party system clone (Solb), not to mention numerous internal projects .... and folks like Primsa (hate to always use them as an example; but they were nice enough to leak some details to the press, so I am free to repeat what has already been published :>) who presumably have plenty of Sun 4/2xx and 1xx and perhaps some of the newer boxes to keep themselves honest .... So far binaries migrate as desired. I assume that the 88K will have this property ... but so far there is limited proof. MIPSco 's customers cannot generally move binaries from Ardent's to SG to MIPS to DEC. This is not necessarily bad; but it does appear to be case currently. > And when latency changes on a Functional Unit (like floating point) >in the future, the 88K register scoreboarding will allow performance >increases WITHOUT CHANGING THE BINARY. Yes. > > Sun networks ALREADY have a massive problem with Sun/3 and Sun/4 >binaries required for everything you use. Don't forget the 386i !! With some "clever" sysAdmin work the "problem" is invisible to most users (modulo disk space requirements). I am no SysAdmin expert, but I often work with all three arch. and various flavors ... and hardly ever care (except when I am checking up on the compiler quality). Over time the cleverness should be eliminated and bulit into tools. >Neither MIPS nor the 88K >have this problem. > In any case, as John pointed out, SPARC does not have this problem either. Sun, as a whole, does because our customers want three different instruction sets for their own reasons ... who are we to argue with them ? btw: does DG intend to drop the MV series ? How is DG better off than Sun ? Is the 88K really binary compatible with the Nova and the MV4000, 8000, 10000, etc. ? >My opinions are my own.... Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
mpogue@dg.dg.com (Mike Pogue) (05/18/89)
In article <105001@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Languages Marketing -- MTS) writes: >MIPSco 's customers cannot generally move binaries from Ardent's to SG >to MIPS to DEC. > >This is not necessarily bad; but it does appear to be case currently. > Yes, in my opinion, DEC's decision to change the endian-ness of the MIPSco processor has minor advantages, and major disadvantages. Does anyone know for a fact that the Ardent binaries are not compatible? >btw: does DG intend to drop the MV series ? How is DG better off than > Sun ? Is the 88K really binary compatible with the > Nova and the MV4000, 8000, 10000, etc. ? > > Ya got me there! DG does not intend to drop the MV series at all. But I notice a big difference running in a Sun environment (Sun/3 and Sun/4s mixed). When I am operating in the DG world, I say "cc foobar" and I can run the application from any terminal at any location. In the Sun 3/4 world, I say "cc foobar" and I move to another location, and have to say "cc foobar" again (while renaming the binaries differently in my working directory, of course). I do have applications in the DG world, however, that run on the lowest machines as well as the highest. We intend to do the same with the 88K (that's one of the reasons we picked it). Those companies that actually manage to do this will, I think, have an advantage. I see that Sparc is now attempting to follow in the footsteps of the 88K BCS! Does anybody know what HP/Apollo intends to do in this regard? :-) Mike Pogue Data General Corp. My opinions are my own....
guy@auspex.auspex.com (Guy Harris) (05/18/89)
> Ya got me there! DG does not intend to drop the MV series at all. But >I notice a big difference running in a Sun environment (Sun/3 and Sun/4s >mixed). When I am operating in the DG world, I say "cc foobar" and I can >run the application from any terminal at any location. In the Sun 3/4 world, >I say "cc foobar" and I move to another location, and have to say "cc foobar" >again (while renaming the binaries differently in my working directory, of >course). I.e., either: 1) You're talking only about MVs or only about 88K machines; 2) The MVs have 88K emulators, or the 88K machines have MV emulators, or both; 3) "cc" produces object and executable code for both machines, so that executable images can be run by either machine. right? (I assume it's not 1), since if that's the case the comparison with the Sun environment would be irrelevant - if you had an all-Sun-3 or all-Sun-4 or all-Sun386i environment, you could run the application from any terminal at any location, assuming it didn't require some device(s) available only on some machines, or something like that.) >I see that Sparc is now attempting to follow in the footsteps of >the 88K BCS! Huh? At the time the AT&T/Sun deal was announced, the prospect of a SPARC ABI was also announced; the ABI has been under development for quite a while. It was hardly inspired by the 88K BCS....