Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: A proposal for the next motion



On 2009-05-19 08:55:22 -0700, Dan Zuras Intervals wrote:
> 	This would add some odd number of tag bits to each interval.
> 	Odd as in strange.  Even an extra 32 bits would be odd.  It
> 	would make an object that is currently a power of two number
> 	of bits into something else.
> 
> 	The tags need not be stored in the same place as the interval
> 	proper but they need to be associated with it in some way.
> 
> 	It makes the hardware task of managing these tags no more
> 	difficult on the hardware guys than managing global state bits
> 	but it makes the task of addressing intervals somewhat more
> 	difficult.  (No more than modern architectures can handle but
> 	not as easy as a power of two.)

Well, not necessarily. This completely depends on the underlying
arithmetic. So, this may be easy or difficult. For instance, if
you use x87 extended precision (a 80-bit format) and need to align
the interval representations on word boundaries (typically 64 bits
nowadays), then you have 32 padding bits you can use for tagging.

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.

For multiple precision, tagging is not much a problem in general.

> > support that idea is another question. I can see at the language or
> > application level that model may work very well, particularly in CAS like
> > Mathematica or something.
> 
> 	Actually I believe the compiler guys will have some difficulty
> 	as well.
> 
> 	Besides the problems mentioned above they would also have to
> 	contend with various possible optimizations.  For example it
> 	might be possible to eliminate the tags altogether if the
> 	compiler can determine that the user never looks at them.

Pragmas can also help the compiler (a bit like FENV_ACCESS in C).

-- 
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)