--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 31, 2006 at 03:21:25PM -0500, Peter Seebach wrote:
> The only thing I can think of that's weird is that my system is compiled
> with:
> 	COPTS?=3D-march=3Dpentium4 -mfpmath=3Dsse -msse2 -O2 -pipe
> I assume this affects kernel builds too.
>=20
> I'm guessing that the sse option is being applied to the kernel, and is
> in some cases resulting in registers that the kernel doesn't think it nee=
ds
> to save getting smashed.  But I don't know; anyone else seen anything sim=
ilar,
> or able to confirm such a theory?

So, assuming that -mfpmath=3D overrides -msoft-float:
I assume the kernel assumes that it never will touch a non-general-purpose
register; yet userland FP math is done in SSE registers and, if -msoft-float
is getting nullified, the kernel will also do (at least most of) it's FP
math in the SSE registers, thus causing userland to clobber kernel and vice
versa.  Any branches based on SSE comparisons will be broken in both.

I'd try a kernel compiled with nothing other than
"-march=3Dpentium4 -O2 -pipe" added.

<rant>
Also, I really dislike the whole not-quite-standard x8[67]
floating point and SIMD model.  They could have defined it
the right way the first time.  Look at the way DEC did the
spec for the Alpha FPU, they even planed ahead for 128-bit
long doubles.  And SIMD should have had a cross-platform
IEEE 754-compatible industry standard to provide a
*portable* API.
</rant>

	Jonathan Kollasch

--gKMricLos+KVdGMg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFEfkK/Ojx1ye3hmokRAugAAJ4m1ka7UCUDA/EaqSHe4f3Egt7upACdG0Y/
8PNE5QcZvXcWQE70owEUvYA=
=tjCq
-----END PGP SIGNATURE-----

--gKMricLos+KVdGMg--