Path: utzoo!attcan!uunet!munnari!otc!metro!basser!natmlab!dmsadel!augean!idall From: idall@augean.OZ (Ian Dall) Newsgroups: comp.arch Subject: Re: Dedicated Processors (was Sw vs. Hw BitBlit (CharBLT)) Message-ID: <378@augean.OZ> Date: 25 Aug 88 04:07:49 GMT References: <399@ma.diab.se> <76700044@p.cs.uiuc.edu> <1843@gofast.camcon.co.uk> <418@ma.diab.se> <374@augean.OZ> <1988Aug22.195431.7991@utzoo.uucp> Reply-To: idall@augean.OZ (Ian Dall) Organization: Engineering Faculty, University of Adelaide, Australia Lines: 63 In article <1988Aug22.195431.7991@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <374@augean.OZ> idall@augean.OZ (Ian Dall) writes: >>... A multi CPU system is seriously complicated by the >>problems of avoiding a memory access bottleneck. > >This is equally true of a multiple PU system. Any system with multiple >processors that want to access memory a lot will run into this. The >usual solution, for both balkanized and unified multiprocessor systems, >is to see to it that most of the memory accesses go to unshared memory of >some kind (cache, local memory, whatever) and shared resources are used >mostly when interprocessor communication is specifically wanted. >Balkanizing the processors -- dedicating some to specific jobs without >giving the software any say in the matter -- does not eliminate the >problem; what it does do is to make cruder and less useful solutions >look acceptable. Well it is a matter of opinion whether a solution is crude or elegant! What is the criteria? If a $5 dedicated microprocessor can save you some communication and or arbitration hardware, simplify your design task and simplify your software then I say go for it! >>To take an extreme case would you REALLY want to do without the micro >>in an ordinary dumb terminal and have the CPU do its work? Of course >>not! ... > >Well, you know, there are 10^10 PCs out there with video boards that do >exactly that... Well I think of a PC as a terminal whose processor runs Messy Dos in its spare time rather than a computer! This happens to be cost effective up to some performance theshold. If the performance metric you want to use is say supporting ten users, then somehow or other you are going to need more grunt. I don't know about you but I think it would be a nightmare to try and design (and I include the software design here) a multi general purpose cpu system with all the processors having access to the bit map memory of ten screens! By the time you got it working it would be out of date! One way to proceed would be to have each CPU only able to access one bit map. That sounds like a dedicated processor to me! >>... It is cheap and convenient to partition the system into >>chunks with a relatively slow (RS232) link between them. > >Ah, but that's not the environment that the previous discussion has been >about. Obviously, if communications are very slow then it makes sense to >have intelligence at both ends. You are assuming that the communications speed is preordained. It is not. The point I was making is that in one's design one might choose to go for lower speed (and lower cost) communications and spend some more money on some cheap dedicated processors to get the same or better overall performance. > Preferably general-purpose intelligence; >an Atari ST or an AT&T 630 makes a much better terminal than an ordinary >dumb terminal, and it's not just because of the graphics. Well, if you only use your Atari to run a terminal emulator program then it sounds very like a dedicated CPU to me! -- Ian Dall "In any argument there will be people on your side who you wish were on the other side." idall@augean.oz