(repeat) hardware requirements are futile
Don't waste another minute worrying about how interval arithmetic might
be implemented in hardware in an ideal world. Much more qualified persons
will address that question when they are economically motivated to do so.
To get to that point, at least conceptually:
0) Start by identifying what's required for the most important
class of interval applications that you can think of.
Don't try to support every
conceivable interval application; that will just slow you down as the optimal
solution for each might be slightly different.
1) Devise a meta-standard for languages supporting that class of applications.
754-2008 took some steps toward becoming a meta-standard for languages but
there was a lot of subtle opposition from people who were more comfortable
with a hardware standard. But the LIA standards are a cautionary example
of a meta-standard that didn't have much effect.
So one could reasonably argue that 1788 would do better to devise a binding
to a specific language - C or C++ or Java or... than to try to come up with
a meta-standard for languages that is both precise enough and vague enough.
2) If 1788 produces a meta-standard, get a language standardization body to
bind it into a language standard.
This is harder than the previous step.
3) Get the language standard robustly implemented in GNU compilers and as many
commercial compilers and operating systems as possible.
This is harder than the previous steps.
4) Get significant realistic freely-distributable
applications implemented in that language.
This is harder than the previous steps. The principal barrier to adoption
of interval methods outside the interval community is unwillingness to
completely rethink the problem and reimplement its solution.
5) Combine several of those applications into a SPEC-like performance
evaluation suite.
This is relatively easy.
6) Get significant hardware procurements to be based upon performance on
that performance evaluation suite.
This is hard too. Vendors who choose not to invest in interval performance
will resist such procurement requirements.
Of course, in reality, all these steps proceed somewhat in parallel.
The starting point and ending point has to be user application requirements.
Hardware implementation does not drive user adoption.
User adoption drives hardware implementation.
We've had thirty years of evidence of that in 754 and ten years at Sun.
Selling unfamiliar tools to unmotivated users is a very hard sell.
On the other hard, the computer industry MIGHT be at an inflection point
like 1977, with new kinds of (GPU) processors and languages developing
to support them. Attached processors have come and gone before,
usually with rather minor impact, but good enough architectural ideas might
migrate to the CPU... or the CPU might migrate to the GPU. Volume drives
cost and performance.
It would be an ironic Pyrrhic victory to get the CPU and its
software stack standardized just as the computational focus moves to
GPU's with even less interval support than current CPU's.