Re: [Qemu-devel] [PATCH v4 5/7] target-m68k: use floatx80 internally

[Richard Henderson]

On 06/19/2017 02:42 PM, Laurent Vivier wrote:
> Le 19/06/2017 à 23:03, Laurent Vivier a écrit :
> > Le 19/06/2017 à 22:53, Richard Henderson a écrit :
> > > It would also make me happier if we were to adjust the definition of
> > > fl0atx80 to more closely match m68k and those missing zeros.  Shouldn't
> > > real hardware move instructions propagate those middle 2 bytes
> > > regardless of contents?
> > >
> > > Perhaps something like
> > >
> > > #ifdef TARGET_M68K
> > >    typedef struct {
> > >      uint64_t low;
> > >      union {
> > >        uin32_t high32;
> > >        struct {
> > > #ifdef HOST_WORDS_BIGENDIAN
> > >          uint16_t high, zero;
> > > #else
> > >          uint16_t zero, high;
> > > #endif
> > >        };
> > >      };
> > >    } floatx80;
> > > #else
> > >    ...
> > > #endif
> > >
> > > (with a minor fix to make_floatx80 to use named initializers).
> > >
> > > Then you can use full 32-bit store insns when copying data here.  Which
> > > also allows you to drop some of the shifts you're needing to add.
> >
> > OK, I will.
>
> The softfloat is in the target independent code, so we can't adjust the
> size of floatx80 by target, TARGET_XXXX are poisoned when used in
> softfloat.h.

Ouch.  That means we'd have to add a full set of floatx96.

If you don't want to do that now, I'd understand.  I'd prefer that you issue an 
undefined opcode exception or something for the packed decimals though, rather 
than just silently dropping 2 bytes of data.

I suppose a first go at floatx96 would be just to thunk the data and call to 
the floatx80 routines.  I do seem to recall that a Proper implementation would 
treat m68k un-normals different from x86.

r~