mash@mips.COM (John Mashey) (05/23/89)
In article <230@ross.UUCP> doug@ross.UUCP (doug carmean) writes: >In reference to the number of software applications running on SPARC: > >Counting applications is even harder than counting mips-numbers. > >...but counting total numbers is very akin to counting average-mips numbers. > >I'm tracking down some current data on this and will post something next week >Yes, counting applications is a somewhat esoteric process, usually >warped to benefit the person that is doing the counting. Please >remember that when someone quotes the number of applications running >on MIPS processors, those applications may or may not be portable >across MIPS based workstations. This is largely due to a major >difference in byte sex between several major vendors. I don't play those games. This was discussed in detail a month of two ago. I never claimed it was optimal. On the other hand, suppose IBM wanted to go SPARC, and use the SPARC compilers, and parts of the OS, but wanted to stick with a SPARC/AIX that wouldn't be binary-compatible with SunOS. Would SPARC-land tell them to go away? or would they rush to sell...... (rhetorical question, of course) This is like selling cars in Japan. One might like to sell standard American cars there. Unfortunately, they drive on the left side of the road over there, and so if you'd like to sell ANYTHING, you've got to put the steering-wheel on the right side.....* At least your car has the same engine, and other components, and controls that are the same here and in Japan, which was more commonality than there was before. (* Except for BMWs and Mercedes, whose steering wheels seem to stay left.) .... >On Cypress: > >33MHz parts were supposed to be sampling almost a year ago, and > >certainly were supposed to be in production 3Q/4Q 88. >with certainty that other companies are not as far behind Sun as Mr. >Mashey would lead you to believe. Look for SEVERAL 33Mhz 601 based >system to be announced late summer/early fall. This will be good for comparisons. > >On high frequency systems: > >FACT: R3000s first sampled about a year ago; at least 2 companies > >(MIPS & SGI) have shipped 25MHz systems, as early as 4Q88. >It would be interesting to compare the total number of 25Mhz R3000 >systems shipped to the total number of 25Mhz SPARC based system in Q4 >of 89. Would you rather be supplying parts to MIPS & SGI or just Sun? >I'd take the latter. Of course; and so would I. Fortunately for our semi partners, most of the MIPS chips go lots of other places these days. > >On multiprocessing (CY7C605): > >(FACT) Note that it is not shipping yet. Note that it seems different > >from the Reference MMU specified a while back, which is also different > >from the ones Sun uses in most SPARC-based products. >Mr. Mashey should get a new copy of the reference MMU spec from Sun >and compare the new spec to the 604/605 descriptions. Like many other >preliminary specs., the reference MMU underwent several revisions >before it finally became a full fledged spec. Both the 604 >(uniprocessing) and the 605 (multiprocessing) conform fully to the >SPARC reference MMU specification. The reference MMU is different >than the MMU that Sun has been using in most of it's SPARC based >products. I don't quite see the problem with this. A well written >operating system only requires a change to a single driver to port it >to a new MMU. This does not render applications unexecutable on >systems with different MMUs. Sorry. There's nothing wrong with this part, as I thought I indicated. (I thought I said these were nice parts and would have helped SPARC-land a lot if they'd existed earlier.) The point was that between the SUN MMU, and the first reference MMU, and the revisions, many potential customers got confused; remember there was once a part described by Cypress to customers: it even had a number, and dates, and it was withdrawn before it ever got built. [Really, I like the 604/605 better, and it was right to dump the previous thing, but this churning around really did confuse people. [FACT, although I'm not allowed to cite specific names.] > >Mr. Mashey continues: > >Presumably there will time for Cypress to make some money on these > >things before the Sun/TI BiCMOS thing obsoletes them.... >If Mr. Mashey knows about the Sun/TI thing, Cypress must know about >the Sun/TI thing. I guarantee that Cypress/ROSS would not be putting >forth the effort to design the 604 and 605 if there was not a proper >time and place for them in the market place. Well, actually, this is good. You have to understand that some pretty amazing dates filter back to us of when things are supposed to exist; maybe they're exagerated. > >I think that Mr. Mashey failed to realize the power of multiprocessor >systems that utilize the 601 IU and the 604/605 CMU chips. Arix Corp. has >announced multiprocessor systems for Q1 of 90 that are based on the >601/604 set. It is clear that all of Mr. Mashey's benchmarks and >extrapolations on future performance are based on uniprocessor >systems. How will the 25Mhz R3000 stack up against a 4 processor >40Mhz 601 system? I don't understand this logic. I compared uniprocessors to uniprocessors, to avoid confusion. One can also compare multis to multis; note that people have already shipped R3000-based multis. Why on earth would one compare a 25MHz R3000 against a 4-CPU 40MHz SPARC? A similar comparison might be a 25MHz SPARC against a 4-way 25MHz R3000 (which is at least contemporaneous, mostly). Now, for the Arix announcement [could you cite a source?]. Since it concerns the future, we have to wait until 1Q90 to see if it really happens. On the other hand, I ahve a really nasty habit of saving press clippings. here are some: check the dates carefully. Also, note there are at least 2 products mentioned here that either never happened or haven't happed when they were said to: 1987: In CSN, October 26, 1987, we find: ``Also, last week, Arete Systems...announced that it would use Sun's SPARC RISC processor in a family of products to be in- troduced during the second half of 1988. Arete will be buying ------------------- its chips from both Fujitsu and Cypress. "What's the use of hav- ing multiple licensees," said Arete CEO Gene Manno, "if you're stuck with just one supplier." .... [I don't think these were pin-compatible....] Manno expects the SPARC products to cap off its computer line. Arete currently markets multiprocessor minicomputers based on the 68000 family chips. The company will abandon that product line, and in fact, intends to develop a 68030-based line when Motorola ------ makes that chip available.'' 1989: In EE Times, February 6, 1989 we find: ``He added that the real action for Arix will come when two CPU boards based on a SPARC implementation from Ross Technology/ Cypress Semiconductor and packing a pair of Motorola's upcoming 68040s, hit the streets.'' (must be typo?) ``Arix Corp, after taking a close look at Motorola's 88000 RISC microprocessor, ..., is instead going to a dual upgrade path with the 68040 processor and the Sun Microsystems SPARC architec- ture. While Manno said the company liked many hardware features of the 68040, such as heavy use of pipelining, Arix engineers were also impressed with the compilers. He said "Motorola did a top-notch job on the compilers." For its first-generation System 90 product line, Arix deliberately went with a 25-MHz 68020 in- ----- stead of the 68030. the company did not like Motorola's on-chip ------ memory management unit and wanted to keep its proprietary MMU in the first boards... Memory management and cache control were also key issues in Arix's RISC strategy. Cypress has opted to halt all work on its own first-generation MMU implementation for SPARC and has elected to await a newly-designed combination cache controller and MMU from Ross.'' >Mr. Mashey pointed out that it is difficult to design systems that run >at 40Mhz, and his point is well taken. Consider that the 25Mhz R3000 >requires two bus transactions per clock cycle, effectively running the >bus at 50Mhz. Even if MIPS could design a 40Mhz Rx000, could you >design a system that allows bus operations at 80Mhz? Of course not, or at least not for a while. At some point, the double-pumped bus runs into brick wall (but NOT because of the caches: there's still a full cycle for each cache access). On the other hand, for clock rates above (something), the current design style of both Cypress SPARC and R3000 becomes impractical, or at least non-optimal, if only because the caches become tough to build. >One of the lures to the MIPS camp has been their very high performance >compilers that they have touted as the best in the industry. I think >that Sun's new compilers will seriously challenge the MIPS compilers >as the best in the industry. We should see some hard data on this soon. We certainly respect Sun's compiler technology. >Finally, Mr. Mashey brings up the question of other vendors producing >more SPARC based systems than Sun. Is this important?.... Some industry analysts think it's an interesting question, for what that's worth. -- -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
les@unicads.UUCP (Les Milash) (05/24/89)
In the midst of a lively debate, folks started talking about: >>Consider that the 25Mhz R3000 requires two bus transactions per clock >>cycle, effectively running the bus at 50Mhz. in the interest of educating ME, what's a "bus transaction"? my guesses are: perhaps some bus that's common for R3000s is multiplexed, sending addr and data in two wads, and so it means the time it takes signals to travel and be latched, although multiplexing the bus in a fast box seems nuts. or perhaps there's some additional signalling, for like multimaster arbitration or cache coherency protocols, and we're talking about this process. or maybe we're just talking about the time it takes some bus driver to charge up the bus, and a read cycle takes 2 of them, and maybe that's the limiting factor with cmos drams and cmos "c"pu's--i dunno. or ... ... duhhhhh? in other words, is a bus "transaction" any more exalted a thing than a bus "cycle"? Les
markw@hpsal2.HP.COM (Mark Williams) (05/25/89)
les@unicads.UUCP (Les Milash) wrote: > In the midst of a lively debate, folks started talking about: > >>Consider that the 25Mhz R3000 requires two bus transactions per clock > >>cycle, effectively running the bus at 50Mhz. > in the interest of educating ME, what's a "bus transaction"? > my guesses are: > perhaps some bus that's common for R3000s is multiplexed, sending > addr and data in two wads, and so it means the time it takes signals to > travel and be latched, although multiplexing the bus in a fast box seems > nuts. > [stuff deleted] > in other words, is a bus "transaction" any more exalted a thing than a > bus "cycle"? > Les The MIPS R2000 CPU has on-chip cache control and talks directly to two off-chip caches (I and D). The cache address lines go to both caches, with the I cache address appearing on one clock phase and the D cache address on the other (latches hold the addresses). This was done to save I/O pins on the CPU. As I recall, the cache data busses are separate (but I could be wrong - it's been 3 years since I looked at this in detail). Obviously, these are not bus transactions between processor and main memory, but only to cache. Whether to multiplex address and data on the processor to main memory bus is an ongoing Holy War not related to the MIPS CPU. And yes, there is a limit on how fast you can make a scheme like this work (say 75 Mhz for CMOS?, 150 for ECL?) but I suspect the MIPS wizards are having fun taking it to the limit.
slackey@bbn.com (Stan Lackey) (05/25/89)
>> In the midst of a lively debate, folks started talking about: >> >>Consider that the 25Mhz R3000 requires two bus transactions per clock >> >>cycle, effectively running the bus at 50Mhz. >> in the interest of educating ME, what's a "bus transaction"? >> in other words, is a bus "transaction" any more exalted a thing than a >> bus "cycle"? The poster you are responding was playing a word game. "Transaction" is a general term, and can apply to something as simple as a single transfer, but carries the exaltedness implication. It was to make the MIPS uP sound stupid, that it has a double-cycled bus, which, in turn, could be a barrier to future cycle time reductions. Of course, the poster was mixing "architecture" with "implementation," a common mistake. And marketing ploy. I will give odds that future MIPS implementations will not have time multiplexed busses if it doesn't make sense, but still be architecturally compatible at the instruction set level. -Stan Disclaimer: Do I have an opinion yet?