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.
Some of the stuff (e.g., rarpd, bootpd, dhcpd etc., libsa) still will
only support Ethernet. Tcpdump itself should be ok, but libpcap needs
lot of work.
For the detailed change history, look at the commit log entries for
the is-newarp branch.
area. These functions are designed to improve performance of large
copyin/copyout operations by mapping the user page in to the kernel
address space and using bcopy(), rather then copying across protection
boundaries.
XXX This doesn't work yet -- the way it's called doesn't obey C calling
XXX conventions. That will be fixed soon.
- copypage() -- a single page-aligned NBPG-byte copy.
- zeropage() -- a single page-aligned NBPG-byte zero.
These functions don't play around with alignment, etc. Their use
causes a measureable performance improvement in pmap_copy_page()
and pmap_copy_page().
A few m68k ports already had copypage() in their locore.s. It has
been moved here so it can be shared.
naming for fmovem, while breaking it for fmove. We probably never will
see normal fmove in the kernel, nevertheless it should be corrected while
somebody remembers.
Besides, the correct patch is smaller and thus easier to verify than the
origininal one.
- add a missing return; at the end of a case, leading to wrong disassembly
of the next few instructions after fmovem.
- while we're here, correct the same bug in PBcc.
XXX there are a few other dubious fallthroughs in this file (which are
not explicitly marked with /* FALLTHROUGH */), which I didn't yet analyze.
* Fix other FMOVEM interpretation bugs:
- correct printing of FP data register lists if all are used (only FP0
would be mentioned)
- correct printing of FP data register lists in the case the list is reversed
(would have printed nothing)
- correct mapping of fp0-fp7 to register list bits (was reversed)
- correct printing of FP control register lists (this list is never reversed)
- correct printing of FMOVEM with FP control registers (the data direction
was interpreted the wrong way)
* While we're here, enhance the comments in MOVC's list of cpu control
registers
scottr