gnu@sun.uucp (John Gilmore) (06/12/84)
> National seems to have decided to do simpler components optimized to what they > consider to be the average use, rather than fancy parts that can be adjusted > to optimize your particular use. In exchange, national was able to produce > their parts, while motorola is still dreaming. Motorola's first parts were simple too, but they've been improving them over the years. (Over half of the 68000 microcode was rewritten for the 68010. Probably all of it is being done again for the 68020.) Nobody can dispute that the 16032's instruction set is seriously orthogonal, while the 68000 series only makes a half-hearted attempt. Nick Tredennick, who wrote the 68000 microcode, claims it's mostly his fault, because he couldn't make it all fit on the chip. The big Motorola win for me is performance. Motorola has shown that they can produce full-speed chips; we had a 16MHz 68000 sample close to two years ago, and many people run 12.5MHz production. People from National keep telling me that the 10MHz part is real, but somehow their customers keep mentioning 6MHz. Does a 6MHz 32032 outrun a 12.5MHz 68000? Also, I got the impression that the 32032 is not even close to twice as fast as the 16032 -- my correspondent seemed to think it ran roughly the same speed, since they didn't increase the internal processing speed even though they doubled the memory bandwidth. (68000-era processors and bus interfaces run at almost exactly the same speed, which means that just widening the bus would not speed them up much.) Motorola is speeding up the processor clock rate, the internal algorithms, the bus width, and the bus cycle time in clocks, while reducing the demand for bus accesses -- all by significant factors. I'll be glad to hear differently if National really did improve the guts of the 16032 to make the 32032 -- can anyone confirm or deny? > You will pay for that extra bit of performance through the nose though. OK, tell me the cost, don't just wave your hands. PS: If you want to build a co-processor of your own, don't try to hang it on a 32032; the CPU decodes the co-processor instructions, so you'll need a new CPU chip too, unless your co-processor instructions look a lot (well, OK, exactly) like their float box's. Motorola got it right. PPS: I'm pleased to see that unlike Intel, National is aggressively encouraging people to hook up their float chip to 68000 systems. Digital Acoustics is having great fun with them; they claim a 12.5MHz 68000 can keep two 16081's busy at once for serious numeric work.
phil@amd70.UUCP (Phil Ngai) (06/13/84)
I had read (in some National propaganda, I think) that all they did for the 32032 was hack the bus interface unit. They also admitted the 16032 was basically compute bound and the 32 bit bus only gained 25% more performance. The marketing department loves it, however. As long as they can say 32 bit bus, who cares if it's faster? I have no particular axe to grind with National's micros. I think their instruction set is nice and their MMU one of the best available (although that isn't saying much). It's a shame that Motorola thinks the way to high performance is to crank up the clock rate. It's really expensive to provide the kind of memory needed by a 16 MHz processor. trying not to be biased, -- Phil Ngai (408) 982-6825 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!phil
nather@utastro.UUCP (Ed Nather) (06/13/84)
[] >It's a shame that Motorola thinks the way to high performance is >to crank up the clock rate. It's really expensive to provide the >kind of memory needed by a 16 MHz processor. > > trying not to be biased, >-- >Phil Ngai This makes no sense to me. Traditionally the cpu operations have always been faster than memory operations, since the same technology applied to either operation favors the simpler. We've learned how to make registers really fast, and cpu operations parallel and individually simple because we can afford to dissipate a lot of power to crunch one word -- but we can't afford the same power in a semiconductor memory system on a per-word basis. It seems to me the best way to make a computer go twice as fast is to double the clock speed. If the memory cost rises more than a factor of 2 we then lose ground on all applications where the cost vs time tradeoff is linear -- not all applications by any means. Now try to get the memory to go faster. Trying to gain a factor of two by changing only the architecture, and keeping the clock speed the same, is terribly difficult if not impossible. I tried it once, and lost. -- Ed Nather {allegra,ihnp4}!{ut-sally,noao}!utastro!nather Astronomy Dept., U. of Texas, Austin
davecl@mako.UUCP (06/15/84)
The following are my impressions based on the instruction set manuals, instruction timings and comments from other people. As far as the bus interface is concerned, the 16032 (which is supposedly now being renamed to the 32016 since the TI announcement) corresponds most closely to the 68008 or 8088. The 32032 corresponds to the 68000 or 8086. In a sense everything was designed for the 32032 all along; the 16032 came out earlier because that was a physical package that could be done sooner. The performance numbers that I've heard is that the 32032 should represent a 25-40% improvement over the 16032, depending on the application. To get a National part with the maturity of development represented by the 68020, you'll have to wait for a later part (like the 32132?). dgc
kurt@fluke.UUCP (06/15/84)
<go ahead bug, make my day> It is true that the 16000 family is compute bound. They typically use only 30-40 percent of the bus bandwidth available. This makes a multiple processor architecture convenient, but this is a side effect not a feature. It is true that the 32032 is just a 16032 with a hacked up bus interface. Internally the processors are identical. Also true is that the 16032 is a full 32 bits wide internally. No matter what the advertising says, the 68000 is 16 bits wide inside. Those 32-bit registers are really pairs of 16 bit registers, and the alu is 16 bits wide (explains the multiply instruction). The 32032 is probably not as much faster than the 16032 as the 68020 will be than the 680[01]0. The 16000 architecture does make it possible for the user to build a custom slave processor. The main processor does decode the instructions and manage the passing of data to and from the slave. This intellegent decision allows the slaves to have available all addressing modes and to transfer all sizes of operand (not just the floating point size). It is actually a pretty good design. It is true that Motorola has substantially improved the microcode in the 68010. It needed it. Part of the change in the microcode allows the 68010 to do virtual memory (to compete effectively with the 16000). It was almost (but not quite) impossible to do instruction abort and restart on the 68000. The 16000 provided this right from the start, along with an instruction set that did not change between mask revisions like it did for the 68000. So...I don't see that National has done any less well than Motorola in bringing the 16000 to market (this is a real success story considering National's checkered record in other areas). Add to this that National did things right from the start with the 16000, and you have my recommendation. No affiliation with National or Motorola. Always my own opinions. -- Kurt Guntheroth John Fluke Mfg. Co., Inc. {uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurt
phil@amd70.UUCP (Phil Ngai) (06/25/84)
When I said "it's a shame National thinks the way to speed up a computer is to increase the clock", I expected people to think of pipelining. I think benchmarks which show how well a particular device performs at 16 MHz with no wait state memory are somewhat misleading in that such memory is quite expensive and either the system will be more expensive or the system won't perform as well in reality. I submit the bus interface of the 286 as an example of a well thought out, efficient memory interface. But I've already gotten on my soapbox about this so I'll just go quietly. -- Phil Ngai (408) 982-6825 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!phil