daveb@geac.UUCP (David Collier-Brown) (08/02/88)
From article <1988Aug1.062659.25971@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer): > To sort of paraphrase a comment the Mips people have made about memory: > think twice before building specialized hardware to do something a > general-purpose CPU can do, because many people are putting enormous > resources into making the g-p CPUs better and faster, and they may well > catch up with you -- probably sooner than you think. Exploiting mass- > market products can work better than trying to compete with them. I have to both agree and disagree with this... I've been burned by the mass market catching up with the performance of special-purpose processors we'd designed, so I can strongly agree with the dictum above. If you want your company to go out of business, just **try** to compete with a silicon foundry. One well-known example is the Lisp machine, which got caught up to in several areas (but not all areas!) as soon as they were released. A less well-know example (on the net) is vCISC technology, which suffers from very high per-generation design costs On the other hand, some functions that a cpu does are "simple" (in some logical sense), and can usefully be encapsulated in an interface, communicated with according to a fixed protocol, and shoved off into a device. If the device is too slow, shove in next weeks' low-cost processor. The week after, shove in the next incarnation of the special device... I see these two approaches as much more of a business-decision problem than an architectural issue: I posted last week the special->general->special cycle that Foley & Van Dam noticed in graphics devices, and suspect that it applies to many more cases than just graphics. > -- > MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology > smells that way. | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu Yea, verily! --dave ps: I'd love to have a board which emulates an X25 line on one side and contains a processor I can program to drive a line of poll-and-select terminals on the other side. Now **there's** a business decision to unmake at high speed! -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers Ltd., | Computer science loses its 350 Steelcase Road, | memory, if not its mind, Markham, Ontario. | every six months.
z8my@vax5.CIT.CORNELL.EDU (07/10/89)
It seems to me, and has been pointed out before, that Herman Rubin of Purdue wants a language, or a language construct to allow him to include non-port- able commands that compile to some specific, machine-dependent code. Unfortunately for him, nearly everyone else in comp.arch (I don't read cop.lang.misc) feels that portability is more important. So can we end this endless argument? Sam Paik d65y@vax5.cit.cornell.edu