Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!cbmvax!mks
From: mks@cbmvax.commodore.com (Michael Sinz - CATS)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: (A) Amy 500 -> 2000? (B) 68040 vs. gfx coprocessor
Message-ID: <9574@cbmvax.commodore.com>
Date: 2 Feb 90 15:36:42 GMT
References: <633@xdos.UUCP> <9527@cbmvax.commodore.com> <640@xdos.UUCP>
Reply-To: mks@cbmvax.cbm.commodore.com (Michael Sinz - CATS)
Organization: Commodore, West Chester, PA
Lines: 122

In article <640@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
>In article <9527@cbmvax.commodore.com> mks@cbmvax.cbm.commodore.com (Michael Sinz - CATS) writes:
>>>Obviously a 25Mhz 68040 with matching memory would be faster at graphics
>>>than the current blitter. On the other hand, it would still be slower
>>>(at BLIT operations) than a 25Mhz blitter, because of the optimal
>>>blitting instructions.
>>
>>But, the 68040 PLUS another chip will always be faster than JUST
>>the 68040 (in a multitasking system) [...]
>>Maybe going with a TI 34010 or 34020 would be the best way, but in any case,
>>making the main processor do the work is wrong.  Yes, it might be
>>faster than the blitter (34010) in a single-task-do-this-now
>>situation, but when more than one thing is going on, that is not
>>the best way.  (Divide and conquer...)
>
>Give me some credit for knowing that multitasking is important! But that's
>not the point. The point is that the 040 is supposed to average 1.3
>instructions per cycle. There are some questions that come to mind as
>a result: how much bus bandwidth is wasted by the processor that is
>even available to be used by a coprocessor??? The answer depends a lot

ahh, but the 68040 also is on the bus *LESS* than the 030.  That is due
to the way the cache and pipeline works inside the 040.  (Like caching
both directions of a branch just in case and even starting the pipeline
with both...)  Some engineers say as much as a 40% reduction of ON-BUS
time with the 040.  (Well, Moto says more, but they quote BEST performance
and not real-world)

[stuff deleted... All good points...]

>But this is too critical of an issue to leave such questions unaddressed.
>You glossed right over all this. If you're convinced that a coprocessor
>still makes sense (the question I raised), then you must have some idea
>of how many bus cycles will be wasted with an 040, and how many clocks
>a memory access would make, including analysis of cache, etc. And whether
>that particular system design would be cost effective in Commodore's market.
>What does it turn out to be?
>
>(See, these dumb sounding questions sometimes have more depth to them
>than it sounds at first. Distrust too-obvious answers!)

Yes, you are correct, however, if you think about other systems that have
these *FAST* cpus, a well designed coprocessor subsystem will always
improve performance.  (By definition of Well designed... ;-)

Just check out what SUN did with the GX board for the sparc systems.
(Like the SPARC-1, a nice little box...)

The 68040 is, as you may already know, designed to fit into multi-processor
systems much more seamlessly than the earlier CPUs.  This is important
since multiprocessing is seen by many as the next major step in solving
the computation intensive tasks that we keep coming up with.  This design
also makes for coprocessors of other design to work very efficiently.
The main thrust has to be in correct design of the system.  You can not
just blindly add a coprocessor and say "DONE"  You and I both agree on that.
The only thing I was trying to point out is that sometimes the coprocessor
may not do a job as fast as the main processor could if that was all the
main processor did, but since the main processor does other things too,
there is still a performance win.

>
>> [In regard to Commodore's foundry:] Yet another "backward" thought.
>
>You know, at the end of your post you say it's not a flame. I'm glad you
>said that, because it kind of sounded like one. I'll point out that it
>wasn't backward at all.

I'm sorry for being so "short" on that statement.  I just get upset when
American companies don't look at the 5-to-10 year picture but only the
1-to-2 year.  Then, after the 2 years, they b**ch and moan to the government
to make protective laws or import limits to help them out.  This is not
just Hi-tech, but everywhere in the US.  I have no sympathy for such
companies.  While I don't know all of the numbers from the foundry
Commodore owns/runs, it may still be cost effective to make it better
as it would not only give us lower chip costs but also make a small
amount of profit too.  (Like, I remember that MOS (back when it was
called that) made many of the 6502 CPUs that were used in Apple and
Atari products.)

[More good stuff deleted...]

>There's nothing that says that vertical integration to the extent of
>maintaining your own chip foundry is always going to be the most cost
>effective of all possible choices!

Like I said, don't know all the numbers and don't have any of the
answers, just my own thoughts and what I had seen at other companies.
Outsourcing does work, but sometimes the costs are higher than you
think.

>There are a very large number of companies that are doing just fine by
>being clients of semiconductor houses, without trying to be one themselves.
>Apple and Sun are two good examples. They certainly have an array of
>interesting agreements with chip houses, without spreading themselves
>thin by trying to be one themselves.
>
>>technology.  C= may not be up to a 1.2 million transistor chip.
>>(That is major size!  And at 0.8 micro it is very small *BIG* chip.)
>
>That's exactly the point. Considering such issues, it makes sense to
>*buy* 0.8 micron chips. Possibly even for coprocessors.

Depends.  If the cost is too high for such a chip.  Technology always
moves forwards.  Once moto has paid for the 0.8 micro foundry with
the 68040, other chips produced there will be only the variable
costs plus yield.  And since you can get more chips on a wafer, the
yield numbers become nicer even if you go from 80% to 70%.  (Maybe)

[final comment about non-flame...]

>	Doug
>-- 
>Doug Merritt		{pyramid,apple}!xdos!doug
>Member, Crusaders for a Better Tomorrow	Professional Wildeyed Visionary

/----------------------------------------------------------------------\
|      /// Michael Sinz -- CATS/Amiga Software Engineer                |
|     ///  PHONE 215-431-9422  UUCP ( uunet | rutgers ) !cbmvax!mks    |
|    ///                                                               |
|\\\///          "I don't think so," said Ren'e Descartes.             |
| \XX/                    Just then, he vanished.                      |
\----------------------------------------------------------------------/