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
exceptions, which puts the address of the instruction we faulted
on in a different location. Copy it and handle as we normally would,
restoring the saved PC before returning.
The FPE should probably be reworked to take advantage of the 68LC040's
precalculated effective address, at some point.
to call mcount(). This is needed because the ``link a6,#0'' insn used
trips up gcc's ANSI preprocessor (A # in a function-type macro must be
followed by a macro argument). _PROF_PROLOG is also used in the i386
asm.h.
Solaris' asm_linkage.h has a MCOUNT macro similar to _PROF_PROLOG
except it expands to different code sequences based on whether a
function is being compiled with "prof" or "gprof" instrumentation.
I also discovered that the m68k ALTENTRY is very different than the
implementation used by other NetBSD ports. Usually ALTENTRY simply
provides an alternate function entry point. The m68k version takes a
second argument and jumps inside the second function when profiling is
enabled. The m68k behavior is similar to the ENTRY2 macro found in
solaris.
Providing ENTRY2 and changing all the code that uses ALTENTRY to use
it would be a desirable change.
This shouldn't break anything; I find ... grep ... all the relevant
kernel sources subdirecotry trees I could think of for the defines
that don't use the new FSLW or FPF6 prefix. But in case it does anyway,
tell me immediately.
jtc