[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hardware .vs. software?

  > From: "chefren" <chefren@pi.net>
  > Date: Tue, 5 May 1998 01:05:35 +0200
  > Subject: Re: Big and little endian issue
  > On  1 May 98 at 0:13, John R Pierce wrote:
  > > Seriously, though, almost any sort of data needs to be
  > > run through the processor at least once on its journey
  > > through a computer system, manual byte swapping shouldn't
  > > take more than a single CPU cycle on most any decent risc
  > > or pipelined cisc architecture, certainly far less time
  > > than it takes to read and write the data.
  > And this leads to what I think is one of of the most
  > fascinating things of these day's: There are more and more
  > functions that were done traditionally in hardware that
  > can be done far cheeper in software. If your CPU runs at
  > hundreds of MHz with tens of KB cache and your bus runs at
  > only 33MHz you have ten or even more cycles to do things in
  > software for -each- bus cycle.

Gee, now why I think these guys are hardware types? :-)

Look at it this way. Install your latest WhizBang SuperDuper
1GB/sec WonderDiskController on your, say, MIPS system.

Now look at that 1GB per second data rate! Ooops, it's much less
than 1GB per second??

Well, gee, AFTER the data is copied to align it to the 8-byte
boundary, and AFTER the cache has been MANUALLY (via software)
flushed/invalidate, and after maybe some byte swapping, then and only
then can the next super fast I/O be started.

THAT's why things like caching (flush/invalidate) should be in
hardware, and why byte alignment requirements are such a problem.

  > A simple form of what Andy Grove called Native Signal
  > Processing that comes into use on a few unexpected points
  > in our last designs. In a small new design it gives us an
  > unexpected 10% price reduction on hardware. For $2.50 we
  > buy a CPU that's twice as fast and only need stupid driver
  > IC's instead of the $10 for two costly highly integrated
  > circuits that others use...

By extending that logic, we can drop all UARTs as well, right?
Knowing the baud rate, just sample the line every X microseconds.

  > Maybe we should start some parallel contests for the
  > shortest BE/LE swapping routines for the most used CPU's
  > and get the "problem" out of this world that way?

Or, we could have a hardware contest ... :-)

Philip K. Ronzone (RON-zone), extension 8300 ..................................
 DIR:(415) 286-8300         (work email)          Electronics for Imaging, Inc.
OPER:(415) 286-8600   Philip.Ronzone@eng.efi.com  2855 Campus Drive
 FAX:(415) 286-8663                               San Mateo, CA