Re: A proposal for the next motion
On 2009-05-21 10:37:30 -0700, Dan Zuras Intervals wrote:
> But as I say above, I am putting my hardware hat on here &
> asking myself what are the difficulties in designing hardware
> to implement intervals that carry tag information with the
> operands & require tag bits in the result.
>
> In this context the problems are: How wide are the busses?
> How many loads are required? Where do I get the tag information
> & at what cost? What special circuits are required? What sort
> of interlocks are required? What is required to store the
> result?
Internally, I don't think that's a real problem, in particular because
some processors *already* take extra bits. For instance, the Itanium
uses a 17-bit exponent. So, one more bit could be added to the bus
width, just like what has been done for the exponent.
> > If you choose to implement interval arithmetic in hardware, you can
> > choose the formats (e.g. as IEEE 754 extendable precision formats,
> > see subclause 3.7) to reserve some bits for tagging.
>
> Yes, but be careful here. It is not required by 754 but it is
> expected that most HARDWARE extensions will use the interchange
> formats defined in clause 3.6.
As processors already support several formats, adding an additional,
very similar, format in hardware would not be a big problem IMHO.
> The freedom allowed the implementer in clause 3.7 is largely
> given to SOFTWARE implementations & is not really thought to
> be the subject of hardware implementations.
If you mean larger formats (e.g. > binary 128), I agree. Otherwise,
in the specific case of hardware interval arithmetic, I don't see
why.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)