Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Computers for users not programmers
Message-ID: <5763@mentor.cc.purdue.edu>
Date: 13 Feb 91 13:36:42 GMT
References: <4772@mindlink.UUCP>
Sender: news@mentor.cc.purdue.edu
Lines: 27

In article <4772@mindlink.UUCP>, Nick_Janow@mindlink.UUCP (Nick Janow) writes:
 
> xxremak@csduts1.lerc.nasa.gov (David A. Remaklus) writes:
 
> > Manipulating byte oriented data with 64 bit word oriented hardware seems kind
> > of slow to me.  It may be a fast processor, but one would think that byte
> > oriented instructions would sure make text oriented processing go a lot
> > faster.
 
> Wouldn't it be better to have an 8-bit coprocessor for handling text?  It could
> be optimized for handling text.  It could have its own memory (8-bit), disk
> access and do 64-bt transfers to/from the main memory.
 
> You could even have an 8-bit multiprocessing module for handling text.  That
> could handle even large text-processing tasks without causing the user to wait.

There was a computer a long time ago which had two semi-independent processors.
Now I do not remember the precise word sizes, so no flames on that, please.
The main computer used 64-bit words and did the number crunching.  There was
a 16-bit computer which did control, address preparation (I believe that it
did not use index registers as we know them), etc.  There were interrupts and
waits to coordinate them, and a part of the main memory was used by the control
computer, and thus was accessible by both.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)