idall@augean.OZ (Ian Dall) (08/16/88)
There are two guite different senses in which one can have a dedicated
processor. A processor can be dedicated (specialised would be a better
word) by its architecture or it can be dedicated in its function.
There is nothing stopping one implimenting a functionally dedicated
processor using a PU (the C has been dropped!) with a general purpose
architecture if that is more cost effective.
If all else was equal it would probably be better to use general
purpose PUs in a multi CPU configuration than to have one CPU with
dedicated PUs dedicated to other functions. However, all else is
rarely equal! A multi CPU system is seriously complicated by the
problems of avoiding a memory access bottleneck.
Functionally dedicated PUs and a single CPU allows for a much cleaner
design than a multi CPU system. In the former case, both the hardware
and the software are more likely to work!
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! The reason it makes sense to put a dedicated micro in a terminal
has little to do with making the best use of the total processing
power of the total system and a lot to do with minimising the cost of
communication. It is cheap and convenient to partition the system into
chunks with a relatively slow (RS232) link between them.
Whether that makes sense for graphics is another matter. I suspect it
depends on your work load. If your programs need to manipulate
bit maps directly then you probably want a wide bandwidth between your
CPU and the graphics memory (and maybe you might as well use multiple
CPUs). But if your programs can describe its display in relatively
high level graphics objects, such as lines, polygons etc. etc. Then
it makes sense to partition your system with a dedicated graphics
processor and a CPU communicating via a relatively slow communication
link like ethernet. I think that most programs in the first
category should be rewritten to fit into the second category.
Whether you make the dedicated processor have a special architecture
or not is a matter of economics and performance (isn't everything?).
If there is only ever going to be a small market for the dedicated
processor then you might well use an off the shelf general purpose
micro. In the case of the graphics processor, however, the market
seems enormous and well worth developing a specialised architecture
for (and TI, NS and Intel seem to agree!).
--
Ian Dall "In any argument there will be people on your
side who you wish were on the other side."
idall@augean.ozhenry@utzoo.uucp (Henry Spencer) (08/23/88)
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. >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... >... 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. 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. -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
idall@augean.OZ (Ian Dall) (08/25/88)
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
henry@utzoo.uucp (Henry Spencer) (08/30/88)
In article <378@augean.OZ> idall@augean.OZ (Ian Dall) writes: >... 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! ... It's been done, actually, although with character displays rather than bitmaps. It worked all right, although the company was so incompetent in other respects that it never caught on. -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu