X-Git-Url: https://git.ucc.asn.au/?p=ipdf%2Fdocuments.git;a=blobdiff_plain;f=LiteratureNotes.tex;h=08b23e12986db46f7e5a155195638286638005f1;hp=39cb25884f6eeebf42701c99651553f4de102f16;hb=c6ca9623378dc9e4517a041ca309a38f36de9e04;hpb=e7fe600f8846251398682d00d3e3a881e9565b7d

diff --git a/LiteratureNotes.tex b/LiteratureNotes.tex
index 39cb258..08b23e1 100644
--- a/LiteratureNotes.tex
+++ b/LiteratureNotes.tex
@@ -379,6 +379,80 @@ Performance was much improved over the software rasterization and over XRender a
 on all except nVidia hardware. However, nVidia's XRender implementation did slow down significantly when
 some transformations were applied.
 
+%% Sam again
+
+\section{Boost Multiprecision Library\cite{boost_multiprecision}}
+
+\begin{itemize}
+	\item ``The Multiprecision Library provides integer, rational and floating-point types in C++ that have more range and precision than C++'s ordinary built-in types.''
+	\item Specify number of digits for precision as a template argument.
+	\item Precision is fixed... {\bf possible approach to project:} Use \verb/boost::mpf_float<N>/ and increase \verb/N/ as more precision is required?
+\end{itemize}
+
+
+% Some hardware related sounding stuff...
+
+\section{A CMOS Floating Point Unit\cite{kelley1997acmos}}
+
+The paper describes the implentation of a FPU for PowerPC using a particular Hewlett Packard process (HP14B 0.5$\mu$m, 3M, 3.3V).
+It implements a ``subset of the most commonly used double precision floating point instructions''. The unimplemented operations are compiled for the CPU.
+
+The paper gives a description of the architecture and design methods.
+This appears to be an entry to a student design competition.
+
+Standard is IEEE 754, but the multiplier tree is a 64-bit tree instead of a 54 bit tree.
+`` The primary reason for implementing a larger tree is for future additions of SIMD [Single Instruction Multiple Data (?)] instructions similar to Intel's MMX and Sun's VIS instructions''.
+
+HSPICE simulations used to determine transistor sizing.
+
+Paper has a block diagram that sort of vaguely makes sense to me.
+The rest requires more background knowledge.
+
+\section{Simply FPU\cite{filiatreault2003simply}}
+
+This is a webpage at one degree of seperation from wikipedia.
+
+It talks about FPU internals, but mostly focuses on the instruction sets.
+It includes FPU assembly code examples (!)
+
+It is probably not that useful, I don't think we'll end up writing FPU assembly?
+
+FPU's typically have 80 bit registers so they can support REAL4, REAL8 and REAL10 (single, double, extended precision).
+
+
+\section{Floating Point Package User's Guide\cite{bishop2008floating}}
+
+This is a technical report describing floating point VHDL packages \url{http://www.vhdl.org/fphdl/vhdl.html}
+
+In theory I know VHDL (cough) so I am interested in looking at this further to see how FPU hardware works.
+It might be getting a bit sidetracked from the ``document formats'' scope though.
+
+The report does talk briefly about the IEEE standard and normalised / denormalised numbers as well.
+
+See also: Java Optimized Processor\cite{jop} (it has a VHDL implementation of a FPU).
+
+\section{Low-Cost Microarchitectural Support for Improved Floating-Point Accuracy\cite{dieter2007lowcost}}
+
+Mentions how GPUs offer very good floating point performance but only for single precision floats.
+
+Has a diagram of a Floating Point adder.
+
+Talks about some magical technique called "Native-pair Arithmetic" that somehow makes 32-bit floating point accuracy ``competitive'' with 64-bit floating point numbers.
+
+\section{Accurate Floating Point Arithmetic through Hardware Error-Free Transformations\cite{kadric2013accurate}}
+
+From the abstract: ``This paper presents a hardware approach to performing ac-
+curate floating point addition and multiplication using the idea of error-
+free transformations. Specialized iterative algorithms are implemented
+for computing arbitrarily accurate sums and dot products.''
+
+The references for this look useful.
+
+It also mentions VHDL.
+
+So whenever hardware papers come up, VHDL gets involved...
+I guess it's time to try and work out how to use the Opensource VHDL implementations.
+
 
 
 \pagebreak