destination register bit pattern with 1.0), which automatically provides
corner case handling.
Missing ftwotox emulation originally reported by Norman Mackenzie in PR 4237,
but he proposed a different implementation.
Only assembly version for i386 bswap16 and bswap32 for now (bswap64 uses
bswap32). Contribution of assembly versions of these are welcome.
Add byte-swapping of ext2fs metadata for big-endian systems.
Tested on i386 and sparc.
movs.
XXX As our CPP seems to hate the 060SP, I couldn't use assym.h for the
PCB_ONFAULT definition, but had to hardwire 64 in the code. This needs
to be fixed ASAP, and will be done in the upcoming reorganization of
the 060sp Makefiles.
- don't erase FPSR exception bits _after_ doing most of the operations in
fpu_implode(), erase them before doing arith and store operations. This fixes
losing the DZ bit.
- create FPSR_OVFL and FPSR_UNFL bits in fpu_implode(). This showed up when
the first error was fixed.
XXX some more work needs to be done. E.g., creating OPERR together with
OVFL looks bogus, but I'm too tired know to re-check docs; and at least we
pass our own regression tests know.
_buserr point to the 68020/030 buserr code _only_. This has broken access
error handling in the 060 support code.
This is repaired by jumping to _buserr60 from the 060SP, and by providing
a _buserr60 label identical to the _buserr in the unchanged m68k ports
using the 68060.
kernels, at the same time getting rid of up to 3 conditional branches and a
bit over one cacheline fetch (for the 68060; the saving is a bit smaller for
040 and yet smaller for the 020/30).
While we're here, also get rid of an redundant lea (using SP-relative
addressing) and of two redundant pushes.
While we're here, also fix a panic which would tear us down on 68060 machines
if a branch prediction error ever occured.
<horimoto@cs-aoi.cs.sist.ac.jp> in PR #3641. I changed the code slightly.
Instead of clearing 13 registers (d1-d7,a1-a6) and zeroing 512 bytes per
loop iteration, I clear 8 registers (d1-d7,a1) and zero 256 bytes. This
reduces the size and complexity of the function.
On the '020, the simpler code is less than 1% slower. Surprisingly, it
is ~3% faster on the '040.
is