home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.arch
- Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!mips!odin!roadkill.esd.sgi.com!gints
- From: gints@roadkill.esd.sgi.com (Gints Klimanis)
- Subject: Re: CISC Microcode (was Re: RISC Mainframe)
- Message-ID: <1992Jul30.063723.21080@odin.corp.sgi.com>
- Sender: news@odin.corp.sgi.com (Net News)
- Nntp-Posting-Host: roadkill.esd.sgi.com
- Organization: Silicon Graphics, Inc.
- References: <55117@mentor.cc.purdue.edu> <id.RKUR.GFF@ferranti.com> <55294@mentor.cc.purdue.edu> <id.GQWR.83D@ferranti.com>
- Date: Thu, 30 Jul 1992 06:37:23 GMT
- Lines: 19
-
- In article <id.GQWR.83D@ferranti.com>, peter@ferranti.com (Peter da
- Silva) writes:
- |> Yes, I quite agree, different problem spaces demand different
- |> algorithms for
- |> solution. However, and this is the key point, it is (in 1992)
- |> extremely rare
- |> that you encounter a constraint on the problem space due to the
- |> hardware that
- |> has any significant effect on the choice of algorithm. Things like
- |> 64K segment
- |> limits, massively parallel hardware, or the absence of a FPU... yes.
- |> Things
-
- Well. I find myself thinking about the MIPS R4000 in my digital audio
- signal processing. Simple things like the tiny 8K instruction and data
- caches really put limits on what you can run at the pipeline rate. The
- 16 floating point registers for mips2 chips imposes severe limits on all
- sorts filter implementations. The limits of new devices are still there
- TODAY.
-