Article View: comp.arch
Article #12425Re: FP-number cache? Unclocked VLSI design.
From: Herman Rubin
Date: Tue, 05 Jan 1993 12:47
Date: Tue, 05 Jan 1993 12:47
37 lines
2506 bytes
2506 bytes
In article <1993Jan5.085415.19676@klaava.Helsinki.FI> veijalai@klaava.Helsinki.FI (Tony Veijalainen) writes:
>This is my third posting in my cracy thoughts series :-)
>There is common trend towards harwardizing the memory lane by separating
>instructions and data to separate caches with own bus to other parts of
>CPU.
>On the other hand FPU-units that appear more and more are in modern big
>CPU:s are quite far conceptually from other operations. I have
>suspision that FP-arithmetic tends to cluster quite heavily, and because
>of traditional efficiency thinking and fixed number arithmetic in
>business applications some big parts of programs are integer only (not
>much FP-operations in interupt code for example :-).
>So have somebody researched the havoc FPU-instructions make to general
>data cache? Is there possible advantage of having FP-number (with
>separate bus to FPU-register file) and fixnumber caches with advantages
>outdoing the cost on CPU (like diminiching the general cache size, is
>this over specialization?).
Those of us who use more sophisticated numerical procedures consider this
to be essentially the opposite direction to go. It is not the case that
integers are only used for addresses and indices; they are vitally needed
for what is commonly called "number-crunching." Fixed-point arithmetic
has great advantages in many situations, and often is so slow in some of
the "modern" machines, especially multiplication, that it pays to go to
the massive headaches of making the floating arithmetic emulate fixed-point
arithmetic. This is especially bad with the formats in which floats are
automatically normalized and with the most significant bit missing, and
where there are even separate registers for integers and floats.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
Technical Details
Message-ID:
<C0Dsuu.7wE@mentor.cc.purdue.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!haven.umd.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubinReferences:
<1993Jan5.085415.19676@klaava.Helsinki.FI>Show Full Headers
Complete Article Headers
Newsgroups: comp.arch Path: arc1-ca.pugleaf.net!sparky!uunet!haven.umd.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin From: hrubin@pop.stat.purdue.edu (Herman Rubin) Subject: Re: FP-number cache? Unclocked VLSI design. Message-ID: <C0Dsuu.7wE@mentor.cc.purdue.edu> Summary: This will only make it worse Sender: news@mentor.cc.purdue.edu (USENET News) Organization: Purdue University Statistics Department References: <1993Jan5.085415.19676@klaava.Helsinki.FI> Date: Tue, 5 Jan 1993 12:47:17 GMT Lines: 37