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
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
simon@dice.UUCP (Simon Kenyon) (07/12/84)
Forgive me for asking, but am I not correct in thinking that these super whizzo ultra fast 68ks are just that: to wit 68000s, and not 68010s. For if that is the case then they are of very little use to anyone, (virtual memory and all that). 32016s and 32032s (as they are now called, I'll always call a 16k a 16k, it is too late to change now) are the way to go, though it is a pity about the string instructions using general registers, and the move multiple instruction, and the fact that just about no instruction sets the b****y condition codes. Anyone out there got genix? We have and would like to talk, exchange firside stories etc. (in a whisper) anyone got a 16k Fortran compiler? Even better if it ran under genix! -- Simon Kenyon. [funny little cute message! ... jeez] { ...vax135!ukc!edcaad or ...decvax!mcvax } !dice!simon 55 51' 49" Lat, 3 31' 46" Long (i.e. this side of the pond)
beaucham@uiucuxc.UUCP (07/12/84)
#R:dice:-12000:uiucuxc:18900006:000:789 uiucuxc!beaucham Jul 12 12:53:00 1984 National is evidentally running Genix on their system, and LMC (Logical Microcomputer in Chicago) says they will be supplying Genix with their system with a month or two. LMC is presently supplying the Unity port (by HCR) which is quite slow, and they are expecting a x2 speed up with Genix. HOWEVER, Unity does include F77 and Genix does not. {my experience with Unity F77 is that it compiles slowly and executes slowly on short programs (x10 VAX780 no fpa) but with long fltng pt executions it does much better (106 sec LMC vs 37 sec VAX on one benchmark).} LMC says it will supply F77 as an option with Genix, but i dont know whose version it will be. please let me know if you hear anything. Jim Beauchamp {ucbvax,pur-ee,allegra,ihnp4}!uiucdcs!uiucuxc!beaucham