[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Languages, languages ... (was: 754R and Reproducibility)



I may be misunderstanding.  But it seems like you would like to require
a set of floating-point operations to be available directly at assembly-
language level.  I think this is a really drastic move.

Not at all!  What I want is the ability for a platform that *does* provide
the necessary primitives to be able to claim conformance.

It has always been the case that a platform that needed some software to
provide complete conformance could not do so without that software.

In 754(1985) that software did not have to be tied to a language.  Now it
does (in current 754R draft); there is no way to describe conformance if
not in the context of a particular language.  A vendor of hardware plus a
couple of programming languages has to claim conformance separately in each
of those languages, or rather, has to defer the conformance claim to the
language standards!  Well, not quite yet -- it is recognised that language
standards will take time to catch up, and the specification *can* now be
deferred to the implementation, e.g. overriding library routines and header
files.

I mentioned assembly language only as an environment that could take direct
advantage of descriptions at the level that I envision, because I'm aware
that this level is very different from that in which most people program
today.  This provides the means for implementing (as library routines or
code generators) conformance at the higher levels.

With your criteria, would such platforms (processor+compiler) still
be able to claim they provide compliant floating-point arithmetic?

Of course!

Btw, technically, my proposal would even allow a Turing Machine vendor
to claim compliance, by publishing the subprograms needed to "complete
the implementation".  That would be silly of course, and there would be
no good reason for anybody to do that.

Your example of a DSP with count-leading-zeros and perhaps other assist
instructions comes much closer however:  it could list the idioms that
can be used for each IEEE 754 operation, and would then be compliant in
my sense, permitting others to integrate those idioms into a higher level
and base their conformance claims on those of the DSP vendor.  Whether it
chooses to do so, or whether it wants to protect its own higher-level
implementation as Intellectual Property, would be the DSP vendor's decision.
I just want the option to be available.

I also want to make clear that such published idioms are NOT a specification
for a conforming implementation -- they more like a reference implementation
which the implementor of the next level can choose to follow, or do better
by picking other idioms.  The reference should however make the semantics of
the primitives clear.

Without the approach I'm suggesting, a vendor of lower levels in the
implementation hierarchy could only claim "enables 754 compliance if the
following, or equivalent, idioms are employed".  Is that good enough?  I
don't think so, because when conformance is only described at the language
level, it would be necessary to describe this enabling in the context of
each language, present or future -- and now perhaps you see the problem.


Michel.
Sent: 2007-07-11 15:43:15 UTC

754 | revision | FAQ | references | list archive