Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!apple!motcsd!xdos!doug From: doug@xdos.UUCP (Doug Merritt) Newsgroups: comp.sys.amiga.hardware Subject: Re: (A) Amy 500 -> 2000? (B) 68040 vs. gfx coprocessor Message-ID: <640@xdos.UUCP> Date: 1 Feb 90 16:28:00 GMT References: <633@xdos.UUCP> <9527@cbmvax.commodore.com> Reply-To: doug@xdos.UUCP (Doug Merritt) Organization: Hunter Systems, Mountain View CA (Silicon Valley) Lines: 119 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 on details, but if it's 30% (to pick a naive number), then with such an architecture you couldn't get more than 30% blitting done per unit time regardless. Now, while it's always nice to get an extra 30%, it might *not* be cost effective. What if it doubled the board production cost? Would 30% still be worthwhile, given the speedup already gotten simply from using an 040? But let's say we used interleaved memory, and separated instruction and data paths to memory. (For all I know this may be forced by the 040 architecture anyway.) So instruction fetches aren't part of the overhead. Let's also say that only one in four 040 instructions reads/writes data memory (the other three being presumed to be register manipulations). And lets say that memory reads/writes consume 1 clock cycle. Then one of every five (point two) clock cycles would use the data bus, and the other 4 would be free for use by a coprocessor. I'm not at all sure that the numbers work out this nicely no matter how you set things up, but if they did, then clearly there'd be a big win for coprocessors, and you'd be quite right. 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!) > [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. >American companies many times >say that it is easier to rest on current "we be best" and not >spend the money on new technologies and research. That is *NOT* >the way you win in the technology and world market. I agree, but you also can't assume that it is even possible for Commodore to continue making their own semiconductors forever without saying why. It *sounds* good to talk about striving and excellence etc, but the amount of money it requires to stay abreast of the semiconductor game these days continues to grow rapidly. It's easy to fault companies for falling behind, but if you're the CEO, it may be a decision of whether to spend $500 million to upgrade an aging chip foundry, or whether to put that same money into R&D for h/w & s/w of your bread and butter products. Personally I think it'd be a really dumb move to put it into upgrading the foundry. 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! >You must always >adapt and grow or you will have to become a partner with one that >does. (or you will go the route of American TV and VIDEO manufactures) >C= may wish to continue to remain in the CHIP business. They do 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. >However, there is still a need for those tiny 10,000 to 100,000 >transistor chips. (the 68000 is in that range...) Yes, but for how long will it continue to make sense for Commodore to do this? What's the market growth?? >PS - No flame intended, just had to get this off my chest... Thanks for saying so. We may continue to disagree on this, but that doesn't mean that either of us is guilty of "backward" thinking. We may just have different backgrounds that lead us to different perspectives on the economics of things. >BTW - 68040 is a major change in the 680x0 family as far as hardware. > It is LARGE. It is sync only. It does not bus-size. It does > not have a co-processor interface. It has a large dual-cache > and memory-feeder (4Kbytes of cache per side...) It should be > loads of fun... Interesting characteristics. It's also not pin compatible with the 030. Lot of interesting tradeoffs, and as you say, loads of fun. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary