[comp.lang.c] Moving floating point values around

m5@lynx.UUCP (Mike McNally) (08/23/88)

How naughty would it be for a compiler for the 386/387 (or 286/287 for that
matter) to move floating-point values with 386 MOV instructions instead
of FLD and FSTP?  It seems to me that as long as some degree of numerical
robustness (whatever that means) is maintained, the compiler should be
able to do this.  After all, C (for example) doesn't guarantee anything about
internal side-effects which take place during the transfer of a floating
point value from one place to another.  This is quite a savings in the case
of the 386/387 (about 60 clock cycles).

Do most compilers do this already, and if so should I assume that I am
working in a technological backwater?


-- 
Mike McNally of Lynx Real-Time Systems

uucp: lynx!m5 (maybe pyramid!voder!lynx!m5 if lynx is unknown)

chris@mimsy.UUCP (Chris Torek) (08/23/88)

In article <4256@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes:
>How naughty would it be for a compiler for the 386/387 (or 286/287 for that
>matter) to move floating-point values with 386 MOV instructions instead
>of FLD and FSTP?

Probably safe: the 4.3BSD C compiler (actually, peephole optimiser)
can be told to change movf and movd instructions to movl and movq
(`/lib/c2 -f').  This is used by the f77 compiler; it improves some
benchmarks rather surprisingly.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

mcdonald@uxe.cso.uiuc.edu (08/23/88)

>How naughty would it be for a compiler for the 386/387 (or 286/287 for that
>matter) to move floating-point values with 386 MOV instructions instead
>of FLD and FSTP?  

>Do most compilers do this already, and if so should I assume that I am
>working in a technological backwater?

Microsoft C for the IBM uses string move instructions. Presumably a pure
386 compiler would use those for 64 bit reals and the integer MOV 
instruction for 32 bit ones.
Under the proper condition it will move more than one variable 
in one instruction.

davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/23/88)

In article <4256@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes:
| How naughty would it be for a compiler for the 386/387 (or 286/287 for that
| matter) to move floating-point values with 386 MOV instructions instead
| of FLD and FSTP?

  This is a particular win for the 386, since it's one instruction.
However, in looking for that construct in code, I conclude that it
doesn't happen often enough to be a big win overall. I'd like to see the
compiler do it as a matter of generating good code, but I wouldn't
expect to see any big change in running time from it.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

jfh@rpp386.UUCP (The Beach Bum) (08/24/88)

In article <4256@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes:
>How naughty would it be for a compiler for the 386/387 (or 286/287 for that
>matter) to move floating-point values with 386 MOV instructions instead
>of FLD and FSTP?

this shouldn't be a bother.  you should be able to use the doubleword
load and store instructions (or the block byte moves if you want) to
move floats and doubles.

the only place you have to watch out for is

	if (f1 = f2)
		...

or some other conditional context.  you have to use the floating point
moves or a floating point test to properly set the condition codes.
-- 
John F. Haugh II (jfh@rpp386.UUCP)                           HASA, "S" Division

    "If the code and the comments disagree, then both are probably wrong."
                -- Norm Schryer

seanf@sco.COM (Sean Fagan) (08/25/88)

In article <4256@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes:
>How naughty would it be for a compiler for the 386/387 (or 286/287 for that
>matter) to move floating-point values with 386 MOV instructions instead
>of FLD and FSTP?

If I remember correctly, both our '286 and '386 compilers will generate MOVS
instructions to push FP-values on the stack;  they might (I haven't checked)
even generate them for non-stack-pushes.  Yep, just dropped into a subshell
and checked:  neither compiler will uses FLD and FSTP if possible (what if
you don't have an FPU?!  Horror!).


-- 
Sean Eric Fagan  |  "An Amdahl mainframe is lots faster than a Vax 750."
seanf@sco.UUCP   |      -- Charles Simmons (chuck@amdahl.uts.amdahl.com)
(408) 458-1422   | Any opinions expressed are my own, not my employers'.

davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/26/88)

Please excuse the long quote, I couldn't take out much more and have
anyone understand what the topic was.

In article <1121@scolex> seanf@sco.COM (Sean Fagan) writes:
| In article <4256@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes:
| > [ could you use integer load and store to move float on 80*86? ]
| 
| If I remember correctly, both our '286 and '386 compilers will generate MOVS
| instructions to push FP-values on the stack;  they might (I haven't checked)
| even generate them for non-stack-pushes.  Yep, just dropped into a subshell
| and checked:  neither compiler will uses FLD and FSTP if possible (what if
| you don't have an FPU?!  Horror!).

I just logged onto a machine running SCO 2.2.2 for 386, and tried this
for both 286 and 386 compilers. While the code:
	a = b;
generates the more efficient code with integer moves or movs,
initializing auto variables is still done with floating operations.
Perhaps that could be mentioned to the people who try to look better on
benchmarks. Example:
	float flt1, flt2 = 1.23;	/* done with FLD, FSTP	*/
	flt1 = flt2;			/* mov eax		*/

The compiler generates the good code for assign other than
initialization even without the -O switch. Half a congratulation for
half a job well done (or is that a job well half done?).

-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

jimv@radix (Jim Valerio) (08/26/88)

In article <4256@lynx.UUCP> m5@lynx.UUCP (Mike McNally) asks if it is okay
to move floating-point values around on the '86 without using the '87
FLD/FSTP instructions.

The IEEE 754/854 standards say:

	"Whether copying without change of format is considered
	an operation is an implementation option."

If you aren't familiar with the 754/854 standards, it may not be obvious
that this means that you are encouraged to do exactly what Mike is asking.
--
Jim Valerio	jimv%radix@omepd.intel.com, {verdix,omepd}!radix!jimv