[v3] oleaut32: Add ARM support to DispCallFunc().

[Donna Whisnant]

> 
> > Ah...  I hadn't tried it on a platform with soft-FP.  And true enough,
> > the compiler wouldn't support the VFP coprocessor instructions without
> > hardware floats.  It could be made to work with soft-FP too, but would
> > at least be a different function for the assembly language part to one
> > that excludes the VFP coprocessor instructions.
> >
> > I think the correct answer for now would be to do the
> > !defined(__SOFTFP__) in my code, just as described in the discussion at
> > the link you sent.  It seems correct since this code is explicitly
> > written for hard-FP.
> 
> I've fixed my Android toolchain and added a configure check to require
> floating point support, so hopefully this will work now.
> 

Is that the best long-term solution?  Wouldn't there be users who might
wish to use Wine with soft-FP on ARM?  I just dug out my old Android NDK
toolchain (one downloaded from android.com prebuilt) from the last time
I was doing Android development (about four years ago) and dumped the
compiler's built-in defines, and confirmed that it was built for
soft-FP, at least as the default.  So I could envision someone wanting
Wine to work with soft-FP.

One example that comes to mind is someone writing an app where they wish
to make certain that data round-trips scaling calculations across
multiple platforms.  For hard-FP, that's usually done with setting the
FP coprocessor configuration for specific modes, such as how
denormalization is handled and/or how infinity is processed.  But, when
interacting with a compound software application (where there's a main
application with plug-in components coming from separate design groups),
there are cases when changing the coprocessor settings would adversely
affect the parent application, and so using soft-FP is often the
solution.

In fact, the application I've been working on that prompted my adding
this function for ARM to Wine in the first place may end up being such
an application (depends on how easily our floating-point janitor
functions port to ARM).  So it seems like the best general solution is
to have two sets of functions, one for hard-FP and one for soft-FP.

I would have to research the soft-FP ABI details to confirm, but I
believe for the soft-FP path it's just a matter of rolling the VT_R4 and
VT_R8 cases in with the VT_I4 and VT_I8, respectively, in
DispCallFunc(), drop the floats from the reg_args structure passed to
the assembly function, and drop the 'vldm' instruction in the assembly
code.

It would just be a matter of deciding if the code looks cleaner to keep
the two totally separate or to just have a few special-cases for the
soft-FP mode.  If you'd like, I can write the soft-FP case and submit
it, and that would keep from backing us in a corner of only supporting
hard-FP with Wine.  It could allow Wine to be used on many other ARM
type devices out there.

Donna