ajayshah@alhena.usc.edu (Ajay Shah) (05/01/91)
In article <1991Apr30.191117.4373@vax5.cit.cornell.edu> umh@vax5.cit.cornell.edu writes: >In article <1991Apr29.164102.11221@kithrup.COM>, >sef@kithrup.COM (Sean Eric Fagan) writes: >> A four- or five-fold performance increase at roughly the same price. >> >> Meanwhile, an R4000 machine, based on everything I've seen and heard, should >> run for about $10k or so (monochrome, I'm sure) and should be quite speedy. > >A MIPS rep today told me to expect ACE machines (the compaq/microsoft etc >group) at $2K to $5K in Q2 92.Of course these will be no cache except the 8K+8K >on the R4000, and crippled in various other ways to be as cheap as possible, >but will presumably still be far above PC/Mac/Amiga performance. This is the first real information I have read about ACE machines. Hmmm, Q2-92: sounds ambitious to me considering we start with no chip, no OS, etc. Would $2k-$5k be without a 17" monochrome megapixel screen? (this is the entry level Sun today). While we can expect dramatic gains in computing over the next two years, I don't think we'll see dramatic gains in monitor technology. Will ACE machines run binaries for today's MIPS machines (or is that a meaningless statement because of DEC byte ordering?) Or will they try to invent an application base from scratch? If so, will they have binary compatibility between machines which boot a MS-DOS and those which boot Unix? Where does the support announced for Intel processors come in? Do they mean the Intel 80586 or the Intel N10? I really hope these guys get something going: much as I like using Sun computers, there should be some real competition else Sun will grow fat! -- _______________________________________________________________________________ Ajay Shah, (213)734-3930, ajayshah@usc.edu The more things change, the more they stay insane. _______________________________________________________________________________
sef@kithrup.COM (Sean Eric Fagan) (05/01/91)
In article <32459@usc> ajayshah@alhena.usc.edu (Ajay Shah) writes: >In article <1991Apr30.191117.4373@vax5.cit.cornell.edu> umh@vax5.cit.cornell.edu writes: >This is the first real information I have read about ACE >machines. Hmmm, Q2-92: sounds ambitious to me considering we >start with no chip, no OS, etc. There is an OS (although it's for the R3000 right now), and rumours I've picked up from several people indicate that MIPS should have a working R4000 withing a couple of months. Compaq and DEC are busily designing right now, and are awaiting the chip before they actually begin productin. >Would $2k-$5k be without a 17" monochrome megapixel screen? With. >Will ACE machines run binaries for today's MIPS machines (or is >that a meaningless statement because of DEC byte ordering?) Yes to the first question. The kernel must deal with binaries of both byte orderings (fun, eh? 8-)). >If so, >will they have binary compatibility between machines which boot >a MS-DOS and those which boot Unix? SoftPC, I am sure. >Where does the support >announced for Intel processors come in? Do they mean the Intel >80586 or the Intel N10? I *believe* that the goal is to support the same OS on both '386s (and '486s, of course) and on the MIPS-based machine. All of the above is based on rumours and comments I've picked up from about 8 or 9 different places, and, while I believe it's true, I have no affiliation with any of the companies involved, so I could be completely off-base. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
guy@auspex.auspex.com (Guy Harris) (05/02/91)
>>This is the first real information I have read about ACE >>machines. Hmmm, Q2-92: sounds ambitious to me considering we >>start with no chip, no OS, etc. > >There is an OS (although it's for the R3000 right now), Well, several OSes. There's Portable OS/2; does that run yet on any MIPS R-series-based machine? There's the new flavor of UNIX, which sounds as if it's going to be an OSF/1-based system, with an SCO label on it (although there are some disturbing statements from SCO about picking up some things from the OSF/1 kernel; I sincerely hope that the new UNIX isn't something with selected bits of OSF/1's kernel in it, but is either fully S5R4-compatible or fully OSF/1-compatbile - no third force, please, we're finally starting to nuke various off-brand UNIXes, I don't want more popping up). OSF/1, I think, runs on a MIPS-based DECstation. There's also S5R4, for which MIPS ports exist; I think they finally announced the MIPS ABI for S5R4. Dunno which, if any, ACE members will offer it. >>If so, >>will they have binary compatibility between machines which boot >>a MS-DOS and those which boot Unix? > >SoftPC, I am sure. If "binary compatibility" means "ability to run DOS programs". As far as I know, however, the ACE MIPS-based machines *won't* boot "a MS-DOS"; they'll boot Portable OS/2. What kind of binary compatibility is being spoken of here, given that? I assume an ACE machine will be able to boot *either* OS/2 *or* UNIX with no hardware changes, just installing a different OS on the hard disk. Whether the UNIX will be able to run OS/2 binaries, or whether the OS/2 will be able to run binaries, I don't know. >All of the above is based on rumours and comments I've picked up from about >8 or 9 different places, and, while I believe it's true, I have no >affiliation with any of the companies involved, so I could be completely >off-base. Ditto for my comments, although isn't SCO involved? Or are you no longer affiliated with SCO?
rteasdal@polyslo.CalPoly.EDU (Falconer) (05/02/91)
In article <1991May01.024228.9685@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > >I *believe* that the goal is to support the same OS on both '386s (and >'486s, of course) and on the MIPS-based machine. Well, yes, that _is_ the stated goal. However, it was this particular sticking point which essentially convinced the Wall Street analysts who turned out in droves for the ACE announcement that the whole thing was a bad joke. If Compaq and Microsoft, which between them ought to be able to do so, had had the balls to defy Intel and make a geniunely clear, unambiguous commitment to Mips and the R4000 architecture, the picture would have been clearer. Instead they chose to muddy the waters for the sake of mollifying Intel - and, I would note, their stocks have all fallen in the wake of the announcement, while Sun's has risen. The smart money's betting ACE is, as Scott McNealy said, "Big hat. No cattle." -- |||||| Russ Teasdale -- rteasdal@polyslo.CalPoly.EDU -- (Falconer) ||||||| ------------------------------------------------------------------------------- "Gentlemen, if we do not succeed, then we run the risk of failure." - D. Quayle
sef@kithrup.COM (Sean Eric Fagan) (05/02/91)
In article <7558@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>There is an OS (although it's for the R3000 right now), >Well, several OSes. >There's Portable OS/2; does that run yet on any MIPS R-series-based >machine? The trade papers have stated that OS/2 NT (New Technology) has been ported to the R3000, and, further, that Microsoft has bought at least one R4000 simulator. I do now know for certain, however, and I don't know any of the OS/2 people at uSoft to ask (as if they would tell me 8-)). >I assume an ACE machine will be able to >boot *either* OS/2 *or* UNIX with no hardware changes, just installing a >different OS on the hard disk. Yes. As far as my knowledge goes, the goal is to be able to boot either OS, and I think they even want to be able to do so from the network. (Diskless OS/2, anyone? *shudder*) >Whether the UNIX will be able to run >OS/2 binaries, or whether the OS/2 will be able to run binaries, I don't >know. I don't think they will. Yes, it would be nice, but I haven't seen any indication that that is a goal. Note, however, that most of my sources are unix-people; given the two OS's in question, I would not be at all surprised if uSoft put binary compatibility into their OS/2 for the machine. In any event, it *would* be nice if all three (ace OS, os/2, and sysVr4) all had at least a workable subset of compatibility (a mini-ABI). Given that all three will be able to do dynamic linking, there's some hope for that, I think. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
rcd@ico.isc.com (Dick Dunn) (05/03/91)
rteasdal@polyslo.CalPoly.EDU (Falconer) writes: > sef@kithrup.COM (Sean Eric Fagan) writes: > >I *believe* that the goal is to support the same OS on both '386s (and > >'486s, of course) and on the MIPS-based machine. (Sean - did you mean "OSes"? ACE intends to have two for the *86 world at least, and I thought they were doing it for the R4000 also.) > Well, yes, that _is_ the stated goal. However, it was this > particular sticking point which essentially convinced the Wall Street > analysts who turned out in droves for the ACE announcement that the > whole thing was a bad joke. If Compaq and Microsoft, which between > them ought to be able to do so, had had the balls to defy Intel and > make a geniunely clear, unambiguous commitment to Mips and the R4000 > architecture, the picture would have been clearer... Can't the same be said for the software non-decision, in which ACE commits to both OS/2 NT and something sort-of-UNIXy? (I can't tell how UNIXy that offering is intended to be, because I've heard some mumbles that say OSF/1 code, others that say OSF/1 API from unspecified code base, etc.) If these folks really wanted to set some unified future direction, and they're going for OS software that has yet to be written, why did they need to pick two directions (times two hardware directions gives four?) instead of one? I may be missing something important, but this aspect of ACE sure looks like one of those "it's a dessert topping; it's a floor polish" skits. Overall, I see ACE as just another industry consortium...neither the largest nor smallest, first nor last, best nor worst. It looks like the idea is to sell iron, and the power of such a huge consortium is to be able to tell you what you "want" (i.e., what you're going to get) without being bothered by pesky user input. It may help things some; I'll be glad to see some non-*86 low-end machines if that can happen, and there are some other areas where they might produce benefit...but don't expect a major bold step into the future from a group which already has decided not to decide on a single direction for either hardware or software. (Decisive- ness is the enemy of market share.) -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...If you plant ice, you're gonna harvest wind.
daveh@cbmvax.commodore.com (Dave Haynie) (05/03/91)
In article <32459@usc> ajayshah@alhena.usc.edu (Ajay Shah) writes: >In article <1991Apr30.191117.4373@vax5.cit.cornell.edu> umh@vax5.cit.cornell.edu writes: >>In article <1991Apr29.164102.11221@kithrup.COM>, >>sef@kithrup.COM (Sean Eric Fagan) writes: >>> Meanwhile, an R4000 machine, based on everything I've seen and heard, should >>> run for about $10k or so (monochrome, I'm sure) and should be quite speedy. >>A MIPS rep today told me to expect ACE machines (the compaq/microsoft etc >>group) at $2K to $5K in Q2 92. Of course, the cheap-ass ACE machines, assuming they really do materialize, will be based on R3000A. >Will ACE machines run binaries for today's MIPS machines (or is >that a meaningless statement because of DEC byte ordering?) The ACE committee at present consists of Compaq, DEC, and MIPS on the hardware side, MicroSoft and SCO on the software side. MIPS wants to sell chips. All the other folks have a vested interest in maintaining as much PC compatibility as possible -- both MicroSoft and SCO apparently want their respective OSs, OS/2 3.0 and SCO UNIX, to be extremely source-level compatible between these "ARC" systems and PClones. PC Clones are little endian. So is DEC MIPS. SCO is little endian flavored OSF, while AT&T is going big endian for their MIPS UNIX port (used on the Sony machines and some others). I don't see anyone here representing big endian interests. >Or will they try to invent an application base from scratch? If so, >will they have binary compatibility between machines which boot >a MS-DOS and those which boot Unix? Where does the support >announced for Intel processors come in? I think they just mean software parity. If you recompile code written for an ACE system, it should run unmodified on a corresponding PClone under the same OS. I guess between OSs, you could always stick to standard function call interface sets, but I really doubt they're going for any cross-OS ABI here. >I really hope these guys get something going: much as I like >using Sun computers, there should be some real competition else >Sun will grow fat! The interesting thing about this ACE effort is not so much the project itself, which seems kind of wacky, but any effort to get a real open RISC architecture system going. Sun seems to have been trying to launch the same thing themselves with SPARC, but the fact that they're a single house generating (at least originally) chip architecture, system software, and final product, they could be a scary plan to sign up for. One of the reasons the PClones were so successful is that Software, Hardware, and Chips were for the most part driven by three separate companies with common though not always purely overlapping interests. ACE seems to have the same basic setup. The worst part of the PClone world was that the fool things were so hardware dependent, you couldn't innovate or cost reduce. A good 90's open system architecture should allow for all of this. It should be possible to plug an ACE (or whatever) card into an Amiga 3000 or a slotted Mac II and run ACE software as a friendly coprocessor rather than the emulation critter any PClone coprocessor board must become in order to work at all. >Ajay Shah, (213)734-3930, ajayshah@usc.edu -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
nather@ut-emx.uucp (Ed Nather) (05/03/91)
As quoted in the NYT, the president of Sun summed up his feeling about this new consortium, using a Texas phrase of long tradition: "Big hat. No cattle." -- Ed Nather Astronomy Dept, U of Texas @ Austin
mash@mips.com (John Mashey) (05/03/91)
(I've just gotten caught up reading the news, so I'll tack all my ACE comments on this posting. I do note that Dave seems to have read more accurate versions of this than some of the previous posters on the topic...) In article <21199@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>>> run for about $10k or so (monochrome, I'm sure) and should be quite speedy. >>>A MIPS rep today told me to expect ACE machines (the compaq/microsoft etc >>>group) at $2K to $5K in Q2 92. I don't think anyone has announced any pricings yet. I would observe that can build a SS SLC-like machine with an R4000, but with less chips. > >Of course, the cheap-ass ACE machines, assuming they really do materialize, >will be based on R3000A. Quite possible; R3000As are certainly allowed. > >>Will ACE machines run binaries for today's MIPS machines (or is >>that a meaningless statement because of DEC byte ordering?) All current MIPS chips can flip byte order dynamically. ARC-compliant machines (i.e., those able to run shrink-wrapped operating systems of ODT and NT) run native little-endian. MIPS, and others, may well build machines that can run that, as well as OS variants that support both the existing MIPS binaries, and the ODT binaries [this is quite feasible, and in fact, not particularly worse than running both BSD and SV and POSIX binaries, as we do right now.] >The ACE committee at present consists of Compaq, DEC, and MIPS on the hardware >side, MicroSoft and SCO on the software side. MIPS wants to sell chips. All MIPS doesn't sell chips.... and it is also on the software side of this, BTW... >>Or will they try to invent an application base from scratch? If so, >>will they have binary compatibility between machines which boot >>a MS-DOS and those which boot Unix? Where does the support >>announced for Intel processors come in? > >I think they just mean software parity. If you recompile code written for an >ACE system, it should run unmodified on a corresponding PClone under the same >OS. I guess between OSs, you could always stick to standard function call >interface sets, but I really doubt they're going for any cross-OS ABI here. Also, NT on MIPS is also expected to run X86 MSDOS and Windows binaries; they have some very clever stuff to do that. Windows binaries are especially useful, as the interface is much cleaner, and you can jump to high-speed native code much quicker. 1. TO SUMMARIZE THIS: 1) There are two portable OS's being worked on: ODT version of UNIX NT (OS/2 3.0) 2) Both of them are intended to be source code compatible at user level across: MIPS Intel 386 and up (but not 286) 3) In both OS cases, the bulk of the OS code is portable. 4) In both hardware cases, hardware that is compliant with an appropriate set of specs will be able to run shrink-wrapped binary OS's. The MIPS version, in particular, is able to hide most of the hardware specificities, like choice of bus. 5) NT will run DOS and Windows binaries, among other things. NT on MIPS is supposed to be able to run X86 DOS and Windows binaries. ODT on MIPS will be able to run Ultrix binaries. >The interesting thing about this ACE effort is not so much the project itself, >which seems kind of wacky, but any effort to get a real open RISC architecture Why wacky? There are perfectly sensible motivations for everybody involved; the whole thing is geared around the following vision: IF you can make CPUs really fast, and still keep them cheap, you can create whole new kinds of applications, especially if you can get out from under some of the weirder compatibility issues deriving from 10-year+ old designs. I do a talk that ends with what you do with 50-100-mips on the desk or in your notebook, but if you don't believe me, you should hear Bill Gates' discussion on this. However, to make it fast, but keep it cheap, you need to have, over the next few years: 1) Highly-integrated processor, so that the clock scales up, and the manufacturing cost and difficulties kept down. [This is part of the reason an R4000 is all on 1 chip.] 2) High-volumes and multiple sources Bill G. says they wouldn't port NT for anything less than 1M/year volumes. 3) High-volume software, in order to keep it cheap enough to be reasonable in this market. And THAT implies that it might be smart to keep as much compatibility, at the application level for sure, and in the higher parts of the OS, with something that already has some serious volume out there. (I.e., there is a rational reason for the Intel stuff, i.e., current reality... Somebody posted something rather rude about various people lacking the courage to defy Intel ... to be polite, this was rather uninformed...) >system going. Sun seems to have been trying to launch the same thing >themselves with SPARC, but the fact that they're a single house generating >(at least originally) chip architecture, system software, and final product, >they could be a scary plan to sign up for. One of the reasons the PClones Sun fought very hard to sign up COMPAQ, Which is surprising, since Scott M has been saying (after ACE): Compaq is a subcontracting manufacturing slave to Intel/Microsoft. Compaq gets credit for two things: the all important interface called the handle on the portable PC, and the EISA bus, which he dismissed as another slow bus we don't need. Other quotes include the idea that PCs and Macs were great IBM Selectric replacements and great file cabinet replacements. Needless to say, Intel fought demonically to stop this whole thing. > >The worst part of the PClone world was that the fool things were so hardware >dependent, you couldn't innovate or cost reduce. A good 90's open system Yes, an excellent point; fortunately, we've learned a lot in the last few years about designing things to allow for this. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94088-3650
edwardm@hpcuhe.cup.hp.com (Edward McClanahan) (05/04/91)
peter da silva writes: > The NeXT and the Amiga 3000UX have the same problem here: they're 68000 > based, so you won't expect any outstanding improvements in the next few > years. Even if NeXT and Commodore make like Sun and switch to RISC processors > your existing machine is likely to be left behind. Though the asynchronous > bus on the Amiga means that a RISC coprocessor board would be quite a > workable compromise. The NeXT bus is much slower, more designed as a > peripheral bus instead of a general backplane like the Amiga's. Is this true? I understand that NeXT uses a 25MHz NuBus (2.5 times the NuBus used in the Mac II series). Besides, a RISC coprocessor board would primarily access on(its)board memory and not be limited by bus speed. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Edward McClanahan Hewlett Packard Company -or- edwardm@cup.hp.com Mail Stop 42UN 11000 Wolfe Road Phone: (480)447-5651 Cupertino, CA 95014 Fax: (408)447-5039
umh@vax5.cit.cornell.edu (05/04/91)
In article <21199@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie) writes: > In article <32459@usc> ajayshah@alhena.usc.edu (Ajay Shah) writes: >>In article <1991Apr30.191117.4373@vax5.cit.cornell.edu> umh@vax5.cit.cornell.edu writes: >>>In article <1991Apr29.164102.11221@kithrup.COM>, >>>sef@kithrup.COM (Sean Eric Fagan) writes: > >>>> Meanwhile, an R4000 machine, based on everything I've seen and heard, should >>>> run for about $10k or so (monochrome, I'm sure) and should be quite speedy. > >>>A MIPS rep today told me to expect ACE machines (the compaq/microsoft etc >>>group) at $2K to $5K in Q2 92. > > Of course, the cheap-ass ACE machines, assuming they really do materialize, > will be based on R3000A. > The Mips rep I spoke to felt that R4000s would be very popular, even in the cheapest machines, for various reasons. One was on chip cache. Another was that the R4000-external world interface can be configured to run at much lower speeds than the chip itself. It might be cheaper to use a 33MHz R4000 +16MHz RAM than try to get a completely 25MHz R3000 system. Also, I suspect MIPs at least are going to push for full 64 bits from the start, to avoid a hassle a few years from now. Is John Mashey in a postion to confirm this? Maynard Handley
mash@mips.com (John Mashey) (05/05/91)
In article <1991May4.161834.4487@vax5.cit.cornell.edu> umh@vax5.cit.cornell.edu writes: >RAM than try to get a completely 25MHz R3000 system. Also, I suspect MIPs at >least are going to push for full 64 bits from the start, to avoid a hassle >a few years from now. Is John Mashey in a postion to confirm this? (last post for a few weeks): the R4000 is a 64-bit chip right now, although testing can always be counted on to find bugs sooner or later. It will take a while to get all of the software together; among other things, we are talking seriously with certain other vendors who have a strong interest in 64-bit C models, to make sure that inconsistencies are at least reasoned, rather than accidental. We didn't go to the trouble of doing this not to use it.... :-) There will a be a 64-bit article in Byte a few months off that talks about 64-bit, especially why people might want it [not just the addressing uses discussed here before, but the integer performance speedup for some kinds of programs. Note that all of the data so far says that it's pretty hard to get much more than .8 SPECint/MHz, and if 64-bit integers helped you get more, that would help. People are doing aterrific job of boosting SPECfp/MHz; SPECint and equivalent integer codes are proving more recalcitrant. Don't expect 2X, but some uses are: cryptography folks like 64-bit mul/div. optimizing compilers do a lot of work on bit vectors. bitblt folks of course love 64-bit ints. Also, there's the humorous use of actually being able to represent financial quantities as integers: observe that even $/cents-denominated values are often too large for 32-bit ints [Yen is about the same as cents, Lira or Won make it worse :-)] -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94088-3650
martelli@cadlab.sublink.ORG (Alex Martelli) (05/05/91)
daveh@cbmvax.commodore.com (Dave Haynie) writes:
...
:The ACE committee at present consists of Compaq, DEC, and MIPS on the hardware
:side, MicroSoft and SCO on the software side. MIPS wants to sell chips. All
I'm pretty sure Olivetti is also in it (they didn't use to be MIPS customers,
and indeed went so far as to announce an Intel860 box, but that was, I believe,
canceled, and they are now going MIPS); and I *think* Sony was also at the
launch, despite the big-endianness and the System V Rel. 4 which, I think, runs
on their current MIPS portable WS (desktop NeWS run pure BSD43, or they used
to until not long ago, at least).mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/07/91)
In article <3005@spim.mips.COM> mash@mips.com (John Mashey) writes: >All current MIPS chips can flip byte order dynamically. ARC-compliant >machines (i.e., those able to run shrink-wrapped operating systems >of ODT and NT) run native little-endian. MIPS, and others, may well >build machines that can run that, as well as OS variants that support both >the existing MIPS binaries, and the ODT binaries [this is quite feasible, >and in fact, not particularly worse than running both BSD and SV and POSIX >binaries, as we do right now.] I don't think it so easy. With the byte order flipping mechanism of R3000, memory, bus and IO is considered to have the same byte sex with the CPU. Thus, it is impossible to share memory (of byte stream) between binaries with different endian. So, shared memory between them is impossible. Moreover, because buffer cache (and OS in general) must have some byte sex, there are difficulties in IO with binaries of the opposite byte sex. Are there any workaround, or dose R4000 have different mechanism for byte flipping? Masataka Ohta
cprice@mips.com (Charlie Price) (05/09/91)
In article <159@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >In article <3005@spim.mips.COM> mash@mips.com (John Mashey) writes: > >>All current MIPS chips can flip byte order dynamically. ARC-compliant >>machines (i.e., those able to run shrink-wrapped operating systems >>of ODT and NT) run native little-endian. MIPS, and others, may well >>build machines that can run that, as well as OS variants that support both >>the existing MIPS binaries, and the ODT binaries [this is quite feasible, >>and in fact, not particularly worse than running both BSD and SV and POSIX >>binaries, as we do right now.] > >I don't think it so easy. > >With the byte order flipping mechanism of R3000, memory, bus and IO is >considered to have the same byte sex with the CPU. > >Thus, it is impossible to share memory (of byte stream) between binaries >with different endian. So, shared memory between them is impossible. >Moreover, because buffer cache (and OS in general) must have some byte >sex, there are difficulties in IO with binaries of the opposite byte sex. > >Are there any workaround, or dose R4000 have different mechanism for >byte flipping? The R4000 does the same sort of thing as the R3000A and the R6000. The *only* time the endian-ness of the processor is relevant is when a partial word (byte, half-word, triple) load or store is performed. The processor uses the endian setting to decide which byte(s) to select from the word or double-word wide cache/memory bus. There is no way (that I know of) to *transparently* share *arbitrary* binary data between big and little endian universes. In the general case, you have to know what the format of the data is and how it was written to know how to read it from the other endian view. If you make a system execute both big and little endian binaries, you get to make one type of binary data share transparently between the universes. To do this, the OS keeps track of the endian-ness of the source/destination of data and does a transform during I/O for non-native sources/destinations. Data is always stored in the native byte order of the machine. The only reasonable choice is to make character streams work correctly. If a program is not the native endianess, the OS flips the bytes in a word end-for-end on transfers to/from the kernel. A non-native text editor can create a text file that the native cat program can display. The cost of doing the data transform for all I/O is not prohibitive. Supporting non-native endianness is clearly a compatibility measure and not the normal way to do business. It is useful in a couple ways: 1) To support programs from both the RISC/os (MIPS Computer Sys), and SVR4 big-endian worlds and the Ultrix (DEC) and the SCO (current and forthcoming OS) little-endian worlds. Presumably as time goes by, machines based on the chip will all become one endian (probably little) and one endianness will dominate in the world of binaries. The fringe applications will convert. 2) To support programs that manipulate data produced in a particular endian format or programs that expect to be run on a particular endian machine. If you have a big-endian compile mode on your little-endian ARC-compliant box, it might be easier to get a big 680x0 or SPARC specific C application running quickly. How well this will work in practice isn't clear to me right now. The problems and confusion may exceed any positive value. -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. MS 1-03 / Sunnyvale, CA 94086-23650
wallace@iitmax.iit.edu (Wallace) (05/09/91)
In article <3225@spim.mips.COM> cprice@mips.com (Charlie Price) writes: >In article <159@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >>In article <3005@spim.mips.COM> mash@mips.com (John Mashey) writes: >> >>>All current MIPS chips can flip byte order dynamically. ARC-compliant >If a program is not the native endianess, the OS flips the bytes in >a word end-for-end on transfers to/from the kernel. >A non-native text editor can create a text file that the native >cat program can display. > >The cost of doing the data transform for all I/O is not prohibitive. ^^^^^^^ My kind of guy! This can be pipelined in the cpu, so, the net cost is one cycle per flip. Not bad! Ralph -- ============================================================================= I am not in search of excellence, I am in search of perfection. Dr. Ralph W. Wallace USPS: Illinois Institute of Technology TEL#: (708) 682-6030 Dept. of Computer Science UUCP: wallace@iitmax.IIT.EDU 210 E. Loop Road BITNET: CSWALLACE@IITVAX Wheaton, Illinois 60187
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/09/91)
In article <3225@spim.mips.COM> cprice@mips.com (Charlie Price) writes: >The R4000 does the same sort of thing as the R3000A and the R6000. >The *only* time the endian-ness of the processor is relevant is when >a partial word (byte, half-word, triple) load or store is performed. Then, shared memory between processes of different endian is impossible. This means that access to a file through memory mapping mechanism is impossible, if the file is accessed from processes of different endian. But, it's OK to me, as I think mapped I/O is a bad idea. >The only reasonable choice is to make character streams work correctly. So, I said: >>Thus, it is impossible to share memory (of byte stream) between binaries ^^^^^^^^^^^^^^ >The cost of doing the data transform for all I/O is not prohibitive. Agreed. The cost is not so small, but, anyway, for disk I/O, the processor must transfer data between user buffer and buffer cache. >Supporting non-native endianness is clearly a compatibility measure >and not the normal way to do business. I hope so. >1) To support programs from both the RISC/os (MIPS Computer Sys), > and SVR4 big-endian worlds and the Ultrix (DEC) and the > SCO (current and forthcoming OS) little-endian worlds. > > Presumably as time goes by, machines based on the chip will all > become one endian (probably little) and one endianness will dominate > in the world of binaries. The fringe applications will convert. I really hope so. But, don't forget that MIPS has been supporting both BSD and SysV and, as time goes by, POSIX. Masataka Ohta
kenton@abyss.zk3.dec.com (Jeff Kenton OSG/UEG) (05/09/91)
In article <1991May9.025504.16646@iitmax.iit.edu>, wallace@iitmax.iit.edu (Wallace) writes: |> In article <3225@spim.mips.COM> cprice@mips.com (Charlie Price) writes: |> >>>All current MIPS chips can flip byte order dynamically. ARC-compliant |> >If a program is not the native endianess, the OS flips the bytes in |> >a word end-for-end on transfers to/from the kernel. |> >A non-native text editor can create a text file that the native |> >cat program can display. |> > |> >The cost of doing the data transform for all I/O is not prohibitive. |> ^^^^^^^ |> My kind of guy! |> This can be pipelined in the cpu, so, the net cost is one cycle |> per flip. Not bad! |> As Charley Price said, this has to be done by the OS. In a test recently, I saw about 150 nanoseconds per byte for swapping. For programs that are completely I/O bound (cp for example) this doubles the kernel's copy loop time but only amounts to 20% of systems time. It has almost no effect on wall clock or user time (which is determined by physical disk or network timing). For non I/O bound programs the time penalty was negligible. ----------------------------------------------------------------------------- == jeff kenton Consulting at kenton@decvax.dec.com == -- Not the official word of Digital -- == (617) 894-4508 (603) 881-0011 == -----------------------------------------------------------------------------
paul@taniwha.UUCP (Paul Campbell) (05/09/91)
In article <32580026@hpcuhe.cup.hp.com> edwardm@hpcuhe.cup.hp.com (Edward McClanahan) writes: >Is this true? I understand that NeXT uses a 25MHz NuBus (2.5 times the NuBus >used in the Mac II series). Besides, a RISC coprocessor board would primarily No, this impression is something that Next marketting have done really well in putting over - it's a 12.5MHz NuBus with a double clocked burst mode, this means that for most accesses you put over it (68030s only burst instructions and the RAM is on the motherboard, '040s require special coding to make them burst - or alternatively you need special hardware to support it) its only 1.25 x the speed of a normal 10MHz NuBus (in fact the best thing you can do for the most common NuBus peripheral (a framestore) is to reduce the single cycle latency to 2-3 clocks a 2 clock 10MHz NuBus (200nS cycle) is much faster than a 4 clock 12.5MHz NuBus (320nS cycle)). NuBus 90 includes the Next double clocking for bursts (they did do a good job inimplementation) but still at 10MHz (by your standards I guess it's a 20MHz bus even though the bulk of cycles run over it will be at 10MHz). Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P My son is now 2 months old, in that time he has doubled his weight, if he does this every 2 months for the next year he will weigh over 300lbs.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (05/10/91)
In article <168@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: > ... > Agreed. The cost is not so small, but, anyway, for disk I/O, the processor > must transfer data between user buffer and buffer cache. It's far faster to fiddle with TLB's, PTE, MP-locks, and so forth than to copy a 4KByte page of words between kernel and user space. It's faster to copy a 4KB page of words than a 4KB page of bytes. There are numbers for the cost to byte swap during a word-copy on certain interesting RISC chips, and while they are not "prohibitive", they are "undesirable." Everyone by now has no doubt noticed the user-level instruction added to the 486 from the 386, the swap-the-bytes-in-a-32-bit-register instruction. INTEL added it despite the fact that you can swap bytes in place in likely registers in 4 instructions, each taking 2 clocks on a 386 or 1 on a 486. 4 instructions is a fraction of what is required elsewhere. Vernon Schryver, vjs@sgi.com
weaver@jetsun.weitek.COM (Mike Weaver) (05/10/91)
In article <576@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM (Larry McVoy) writes: (About ACE machine): >Q2 '92? I suppose it could happen. I'll be very impressed. Consider these rumors that are probably facts: 1. MIPS has R4000 samples in-house now. 2. MIP has had a R4000 hardware simulator for some time, available to e.g. Microsoft. 3. Microsoft OS/2 derivitive for MIPS has been demoed to MIPS. (Microsoft appears to have been on this project for 1-2 years). If these are true (and of course, some may not be), what remains to be done is the hardware design of the box, making the OS stable and reliable, and getting a few good applications ready to go. One year is an aggressive schedule for all of this, to be sure, but not unrealistic. Myself, I think the bigger question is not whether the thing can be made, but whether it can be sold in sufficient quantity to get the 'critical mass' needed to make it a product line with a life of its own. Michael Weaver.
bhabeck@hpcuhe.cup.hp.com (William Habeck) (05/11/91)
Daniel Mocsny (dmocsny@minerva.che.uc.edu) writes: >Will MIPS, SPARC, or HP-PA CPU run any binary compiled before the year >1985? That is what I meant by "very far backwards". (See that I >qualified my claim with "seems": I don't claim to have expertise >here.) PA-RISC machines with MPE XL (the HP 3000 Series 900) will run binaries compiled in 1973 for the HP 3000 Series II, a 16-bit stack machine. MPE XL recognizes them and runs an emulator (called Compatibility Mode). The performance hit is about a factor of three versus recompiling if the program spends most of its time in user code (the system functions have been recompiled to run natively). There is also an object code translator which makes (inefficient) native-mode binaries out of "Classic 3000" binaries. These tools were critical (and still are) for moving the installed base of 30,000 HP 3000s to the new architecture. But I think IBM has more to brag about since its 3090s run 360 binaries compiled in the 1960's (or so I've heard). On the other hand, I believe 360 code has a hard time on System 34, System 36, System 38, the AS/400 line, and the PS/2. Looking forward, I think the i786 (whenever it comes out) will still run 8088 binaries. And the Motorola 68060 will probably run 68020 code. >Are we likely to see the fastest CPU in year X being able to run, >without change, a binary program more than 5 years old? (Does HP-PA >do this right now? If so, I am very impressed. I would be much more >impressed if it could also run the large existing libraries of >CISC binaries at full speed, but that would be asking quite a bit :-) The earliest PA-RISC binaries were probably compiled in 1985 and they run native (and about 10 times faster) on the Series 700 in 1991. That's over five years. Are you impressed? :-) -- Bill Habeck, Hewlett-Packard Company bhabeck@hprasor.cup.hp.com Not a statement of HP. No warranties. Corrections welcome. Etc.
halkoD@batman.moravian.EDU (David Halko) (05/18/91)
In article <32580026@hpcuhe.cup.hp.com>, edwardm@hpcuhe.cup.hp.com (Edward McClanahan) writes: > peter da silva writes: > > > The NeXT and the Amiga 3000UX have the same problem here: they're 68000 > > based, so you won't expect any outstanding improvements in the next few > > years. Even if NeXT and Commodore make like Sun and switch to RISC processors > > your existing machine is likely to be left behind. Though the asynchronous > > bus on the Amiga means that a RISC coprocessor board would be quite a > > workable compromise. The NeXT bus is much slower, more designed as a > > peripheral bus instead of a general backplane like the Amiga's. > > Is this true? I understand that NeXT uses a 25MHz NuBus (2.5 times the NuBus > used in the Mac II series). Besides, a RISC coprocessor board would primarily > access on(its)board memory and not be limited by bus speed. > I have seen this statement over and over again "they're 68000 based, so you won't expect any outstanding improvements in the next few years" This upsets me since the relative performance of the 68040 over the 68030 was over a 100% improvement in speed at the same CPU speed, according to some of the journals I read about 1 year back. Motorola expects another 100% speed increase with the release of the next 68K CPU. This may be another year away, but I think it is worth the wait. A 25 MHz backplane is a quick backplane, definitely not slow! The analog bus, while superior in many ways, doesn't mean that it is any slower. I syncronous 25 MHz bus and asyncronous 25 MHz bus should be about the same speed, but the analog bus should be slightly slower due to the handshaking needed which is not required for the syncronous bus. Am I off target here? The main advantage of an analog bus is the ability of the other cards over the bus to run at a slower speeds. All the cards on the bus who are using the bus (master and slave card during the communication) operate as fast as the slowest card can communicate. With a syncronous bus, all cards must operate at the same clock rate, which means problems when you start increasing the clockrate of the CPU on the bus, in general. Thus, the reason why most high performance systems out there are on VME bus for the Motorola CPU. How accurate is this assessment? Dave Halko -- _________________________________________________________________________ / "The use of COBOL cripples the mind; its teaching should, therefore, be \ / regarded as a criminal offence." E.W.Dijkstra, 18th June 1975. \ +-----------------------------------------------------------------------------+ \ "Have you purchased a multi- halkoD@moravian.edu Have you booted your / \ media machine from IMS yet?" David J. Halko OS-9 computer today?/ \_______________________________________________________________________/
melling@cs.psu.edu (Michael D Mellinger) (05/20/91)
In article <4638@batman.moravian.EDU> halkoD@batman.moravian.EDU (David Halko) writes:
I have seen this statement over and over again "they're 68000 based, so you
won't expect any outstanding improvements in the next few years"
This upsets me since the relative performance of the 68040 over the 68030
was over a 100% improvement in speed at the same CPU speed, according to
some of the journals I read about 1 year back. Motorola expects another
100% speed increase with the release of the next 68K CPU. This may be another
year away, but I think it is worth the wait.
A 25MHz 68040 is at least 3 times faster than a 25MHz 68030. At least
that is the performance increase I saw in the NeXT when it was
upgraded. The 68040 is competive with the SPARC(Sun's SparcStations)
at the same clock speed, and I doubt if GCC is the best optimizing
compiler in the world. It will be interesting to see what happens
when Motorola gets a 40MHz 68040. Personally, I think 68000 based
computer companies will move to the 88K. Moto. will double or triple
its performance at the same clock speed(same as the 040 I think, and
available 2 years ago) long before we see a 68050.
-Mikedaveh@cbmvax.commodore.com (Dave Haynie) (06/04/91)
In article <4638@batman.moravian.EDU> halkoD@batman.moravian.EDU (David Halko) writes: >In article <32580026@hpcuhe.cup.hp.com>, edwardm@hpcuhe.cup.hp.com (Edward McClanahan) writes: >> peter da silva writes: >> > The NeXT and the Amiga 3000UX have the same problem here: they're 68000 >> > based, so you won't expect any outstanding improvements in the next few >> > years. Even if NeXT and Commodore make like Sun and switch to RISC processors >> > your existing machine is likely to be left behind. Though the asynchronous >> > bus on the Amiga means that a RISC coprocessor board would be quite a >> > workable compromise. The NeXT bus is much slower, more designed as a >> > peripheral bus instead of a general backplane like the Amiga's. >> Is this true? I understand that NeXT uses a 25MHz NuBus (2.5 times the NuBus >> used in the Mac II series). Actually, I've heard both that the NeXT uses a 25MHz NuBus clock and that it uses a 12.5MHz NuBus clock. Anyone know for certain? >This upsets me since the relative performance of the 68040 over the 68030 >was over a 100% improvement in speed at the same CPU speed, according to >some of the journals I read about 1 year back. At least. But everyone reads specsheets these days, and when you see specsheets for HPs and MIPS R4000s and all, the 68040 is judged only a small improvement. When you have one one your desk, you find it a big improvement. Everything's relative... >A 25 MHz backplane is a quick backplane, definitely not slow! The analog bus, >while superior in many ways, doesn't mean that it is any slower. I syncronous >25 MHz bus and asyncronous 25 MHz bus should be about the same speed, but >the analog bus should be slightly slower due to the handshaking needed which >is not required for the syncronous bus. Am I off target here? Analog bus? We're all digital here, really. The Amiga 3000's expansion bus was designed as an asynchronous bus for a number of reasons. First of all, your NuBus-style synchronous bus is always tied to that bus clock. You get into ugly synch-up/synch-down delays unless the bus clock and the processor clock are derived from the same base clock. On the 3000's bus, there are no inherent synch delays, though there may be in any given implementation of master or slave. There's also no inherent clock; as long as you meet setup and hold times for a couple of strobes, you're golden. So while the current system drives the bus based on a 25MHz clock, a future system or bus master could drive it based on a 50MHz clock. Because of the handshaking, slaves will work to the best of their ability with the current bus master. >The main advantage of an analog bus is the ability of the other cards over >the bus to run at a slower speeds. All the cards on the bus who are using >the bus (master and slave card during the communication) operate as fast >as the slowest card can communicate. Actually, on the _asynchronous_ bus, the speed of any given transaction is determined by the master and slave involved. Slave and masters not involved in a bus transaction have no effect on the speed of that transaction, but all masters and slaves will be able to communicate with one another. >With a syncronous bus, all cards must operate at the same clock rate, which >means problems when you start increasing the clockrate of the CPU on the >bus, in general. Slaves certainly can add wait states, of course. But in general, clocked buses define a maximum clock rate. Beyond that rate, nothing is expected to work. The advantage of a synchronous bus is generally that it's easier to design for; all your timing can be derived from a bus clock. In the A3000 bus, we did attempt to keep some of this flavor by providing strobe edges where you need them for bus events. Synchronous buses often allow the bus clock to be used for state timing, which is impossible on the asynchronous bus. Not every card needs a state clock, but those that do must provide their own and resolve any synchronization issues, thus making the asynchronous bus sometimes more complicated to design for. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "This is my mistake. Let me make it good." -R.E.M.
paul@taniwha.UUCP (Paul Campbell) (06/05/91)
In article <22152@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <4638@batman.moravian.EDU> halkoD@batman.moravian.EDU (David Halko) writes: >>> peter da silva writes: >>> Is this true? I understand that NeXT uses a 25MHz NuBus (2.5 times the NuBus >>> used in the Mac II series). > >Actually, I've heard both that the NeXT uses a 25MHz NuBus clock and that it >uses a 12.5MHz NuBus clock. Anyone know for certain? Yeah, they do both, the basic bus is a 12.5MHz NuBus (12.5/25 is a 'nice' number if you have a 25MHz CPU - everything is synchronous) - they have a special burst mode which is clocked at 25MHz - the bus has 2 clocks 12.5/25. NuBus 90 has picked up the Next clocking/burst scheme (it is a nice design) and added it to existing NuBuses at 10/20MHz (for compatability). >>A 25 MHz backplane is a quick backplane, definitely not slow! The analog bus, >>while superior in many ways, doesn't mean that it is any slower. I syncronous >>25 MHz bus and asyncronous 25 MHz bus should be about the same speed, but >>the analog bus should be slightly slower due to the handshaking needed which >>is not required for the syncronous bus. Am I off target here? Next solve this by driving everything with the CMOS driver ICs, having short backplanes and requiring the driver/controller chips to be physically right next to the bus. The also terminate it so that it gets exactly one reflection within the bus settling time. I don't work for Next, I'm just a poor NuBus designer who has to keep up with the world :-) Paul Campbell -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P My son is now 2 months old, in that time he has doubled his weight, if he does this every 2 months for the next year he will weigh over 300lbs.
daveh@cbmvax.commodore.com (Dave Haynie) (06/07/91)
In article <863@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: >In article <22152@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <4638@batman.moravian.EDU> halkoD@batman.moravian.EDU (David Halko) writes: >>>> peter da silva writes: >>>> Is this true? I understand that NeXT uses a 25MHz NuBus (2.5 times the NuBus >>>> used in the Mac II series). >>Actually, I've heard both that the NeXT uses a 25MHz NuBus clock and that it >>uses a 12.5MHz NuBus clock. Anyone know for certain? >Yeah, they do both, the basic bus is a 12.5MHz NuBus (12.5/25 is a 'nice' >number if you have a 25MHz CPU - everything is synchronous) - they have a >special burst mode which is clocked at 25MHz - the bus has 2 clocks 12.5/25. OIC. So this is a special mode over and above the NuBus "block transfer". >NuBus 90 has picked up the Next clocking/burst scheme (it is a nice design) >and added it to existing NuBuses at 10/20MHz (for compatability). I had read something about an enhanced NuBus being supported by Apple some time in the future, but I had no idea where it came from. So this clocking scheme is fully upward compatible and all? Sounds like a pretty cool solution. And although I still prefer asynchronous buses, a 20-25MHz bus running synchronous to your local bus is certainly no slouch, at least for a PC/PW system. >Next solve this by driving everything with the CMOS driver ICs, having short >backplanes and requiring the driver/controller chips to be physically right >next to the bus. The also terminate it so that it gets exactly one reflection >within the bus settling time. Sounds about right. I stayed away from CMOS buffers on the Amiga 3000 bus (though some of the signals are driven by a CMOS ASIC), mainly for speed concerns, though I was also worried about noise. We had to stay with TTL levels for compatibility reasons, but the buffer drive, speed, and backplane termination was chosen for support of the 32 bit bus. Nowadays, with FCT and ACTQ parts being pretty common, even in the relatively weird types like 74x646, I'll probably use TTL-level CMOS buffers in the future. Though I just got some samples of these new "FR" parts.... -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "This is my mistake. Let me make it good." -R.E.M.
paul@taniwha.UUCP (Paul Campbell) (06/08/91)
In article <22236@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <863@taniwha.UUCP> I wrote: >>Yeah, they do both, the basic bus is a 12.5MHz NuBus (12.5/25 is a 'nice' >>number if you have a 25MHz CPU - everything is synchronous) - they have a >>special burst mode which is clocked at 25MHz - the bus has 2 clocks 12.5/25. >OIC. So this is a special mode over and above the NuBus "block transfer". I think from memory that NextBus just doubles it's burst rates, I don't think it supports 'normal' NuBus burst transfers >>NuBus 90 has picked up the Next clocking/burst scheme (it is a nice design) >>and added it to existing NuBuses at 10/20MHz (for compatability). > >I had read something about an enhanced NuBus being supported by Apple some time >in the future, but I had no idea where it came from. So this clocking scheme >is fully upward compatible and all? Sounds like a pretty cool solution. And I don't think Apple have announced any NuBus 90 Macs - but they were heavily involved in the NuBus 90 effort. Yes they stole some of the -5v (ie ECL) power lines that no one ever used and turned them into a new clock (20MHz) and some controll lines - it supports all the current transfers as well as the new double speed burst transfers (and a way to drop back to the slow modes if the remote board doesn't speak the new ones) and a few other things such as an optional cache coherency protocol, a serial bus etc etc - they also did some minor bug fixes to the original spec. >>Next solve this by driving everything with the CMOS driver ICs, having short >>backplanes and requiring the driver/controller chips to be physically right >>next to the bus. The also terminate it so that it gets exactly one reflection >>within the bus settling time. > >Sounds about right. I stayed away from CMOS buffers on the Amiga 3000 bus >(though some of the signals are driven by a CMOS ASIC), mainly for speed >concerns, though I was also worried about noise. We had to stay with TTL >levels for compatibility reasons, but the buffer drive, speed, and backplane >termination was chosen for support of the 32 bit bus. Nowadays, with FCT >and ACTQ parts being pretty common, even in the relatively weird types like >74x646, I'll probably use TTL-level CMOS buffers in the future. Though I >just got some samples of these new "FR" parts.... Well Next went CMOS, NuBus 90 of course has to stay with the same old drivers so that all the existing cards still work OK - besides we have bigger backplanes etc etc. Paul Campbell -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P Tom Metzger's White Ayrian Resistance has been enjoined to stop selling Nazi Bart Simpson t-shirts - Tom of course got it wrong, Bart is yellow, not white.