881/2 produces unnormalized outputs???

[Stuart Mcdonald]

This has probably been discussed before, but why does
the Motorola 881/2 leave an unnormalized result in a FP
register when, in fact, the value can be normalized?
This only occurs when running in SINGLE or DOUBLE
precision mode AND the answer is subnormal in that
precision mode. For example, squaring

		3FBF 80000000 00000000

produces

		3F81 20000000 00000000

with SINGLE precision mode set.  Even writing this extended to memory
won't normalize it while precision mode is set to SINGLE!  Of course,
writing it to a single or double precision variable will (sub)normalize
it properly since singles and doubles have no redundant encodings.

If a compiler doesn't allow declaring extendeds this is a moot point.
However, if extended variables are allowed, or parameter passing is by
extendeds, it would seem this impacts the implementation IEEE recommended
functions, such as NEXTAFTER, if they are cavalier about precision
control.  That is, algorithms requiring their extended inputs to be
normalized, must temporarily set the precision mode to extended to force
a normalization; I know of no other way of forcing the normalization.

Has anyone else dealt with this issue?

-Stuart McDonald