Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!usenet.ins.cwru.edu!peregrine!csduts1!xxremak
From: xxremak@csduts1.lerc.nasa.gov (David A. Remaklus)
Newsgroups: comp.arch
Subject: Re: Computers for users not programmers
Message-ID: <1991Feb13.180108.13480@eagle.lerc.nasa.gov>
Date: 13 Feb 91 18:01:08 GMT
References: <4772@mindlink.UUCP>
Sender: news@eagle.lerc.nasa.gov
Reply-To: xxremak@csduts1.UUCP (David A. Remaklus)
Organization: NASA/Lewis Research Center, Cleveland
Lines: 32

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.
>:)

Your missing the point.  I wholly agree that it is ludicrous to use
a CRAY for 'text' processing, but compiles, editing, link editing,
grep'ing, etc. are fall under my heading of 'text' processing.  Regardless
of the appropriateness, CRAYs perform these functions.

I agree that an 8 bit (or 16 or 32 bit) micro is better suited for this
type of computing, but the problem remains that the ellusive
'seamless environment' has yet to be created so people use their CRAYs
for edits, compiles, and other UN*X utility programs.

--
David A. Remaklus		   Currently at: NASA Lewis Research Center
Amdahl Corporation				 MS 142-4
(216) 642-1044					 Cleveland, Ohio  44135
(216) 433-5119					 xxremak@csduts1.lerc.nasa.gov