> I think we should define the semantics of round, ceil, floor, etc. without
> reference to FPU flags. These semantics should be encoded in the test
> cases. (I think Peter has already done a lot of this.) The implementation
> needs to match these semantics, no matter the cost.
> If these semantics don't match the current (last week's) implementation, we
> should think about whether we should be introducing new function names for
> backward compatibility. If we don't, we run the risk of previously working
> programs suddenly not working.
I fully agree with that.
> If we implement the assembly versions, then we run the risk of the FPU flags
> not being the in correct mode. From what I understand, it is extremely
> unlikely for the flags to be incorrect for the places where vnl would be
> used, so the set+restore option is too expensive. Is there an assert that
> we can place to verify that the FPU flags are what we expect? That way, it
> won't be a silent failure, at least on a debug build.
Having a non-default FPU mode indeed seems unlikely but the
documentation should make it clear that the rounding functions won't
work properly if the user changes it...
Anyhow, allowing the use of an assert is what we propose. We actually
use the following piece of code:
> I think vnl is probably the most widely used part of vxl, and so it is
> worthwhile to be cautious about fundamental changes in semantics.
Definitely seems reasonable.