Other poeple have tried the same trick before, the problem is that not
all 8 byte sequences are valid floating point numbers, these make the
FPU produce a floating point exception and screwup the copy. Unless you
have discovered how to disable all the FPU checks or/and mask the exceptions
you can't copy arbitary data this way.
That's correct if the floating point instructions (fldq/fstpq) are
used, but the instructions fistpq and fildq store and load 64-bit
integers. Since the FPU registers are internally 64 bits mantissa and
15 bits exponent, there is enough precision to hold any 64 bit
integer. I ran tests of my routine for about 24 hours, using random
bit patterns, and I didn't have a single error of any kind.
The failures I'm seeing are very different from those observed using
the floating point instructions. The failure I'm seeing now is the
very first 64-bit word in a page occasionally gets 7 null's followed
by a byte with the high bit set, and only when RCS is used with mmap()
enabled. I've seen no other crashes or data corruption.
-- Robert Krawitz <rlk@tiac.net>Member of the League for Programming Freedom -- mail lpf@uunet.uu.net Tall Clubs International -- tci-request@think.com or 1-800-521-2512