Re: A proposal for the next motion
> Date: Thu, 21 May 2009 11:39:58 +0200
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: STDS-1788@xxxxxxxxxxxxxxxxx
> Subject: 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.
Well, yes Vincent, this would be true for a software
implementation of intervals on top of some hardware with
possibly unknown characteristics. And your 80-bit example
contains some seed of the alignment problems involved.
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?
My answers (off the top of my head) are:
Busses? Loads? Existing busses could be used if one
is willing to (possibly) do an extra load cycle to get
the tags. Alternatively, the busses could be widened
to make that unnecessary. The former is cheaper. The
latter is more expensive but improves the performance
of other operations as well.
Tag cost? Special circuits? Interlocks? The cost of
getting the tags from memory is detailed above. It is
to be compared with getting the tag bits from a PSW or
some such global source. No special circuits are
needed & no new instruction conflicts are created. The
interlock situation is interesting in that confining all
exception state to tags that are associated with the
operands has the effect of ELIMINATING instruction
interlocks that exist today in concurrent or parallel
hardware implementations. This would likely be a minor
performance improvement today but has the potential to
be a MAJOR performance improvement in the highly
parallel machines of the near future.
The store? Is much the same as the load & could be
cheaply implemented with two store cycles or more
expensively implemented with one store on a wider bus.
Although, as in your 80-bit example, some machines
would implement the store as a read-modify-write cache
line operation so as to fit an odd-bit store into a
larger aligned cache line.
That's my quick reading of the situation.
With different hardware guys, your mileage (kilometerage?) may
vary. :-)
>
> 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. 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.
Although it is not thought that an implementation will violate
the expectation of either clause, any implementation that does
so would still conform to 754.
>
> For multiple precision, tagging is not much a problem in general.
Of course. - Dan
>
> > > . . .
> >
> --
> 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)