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.
Added support the new instructions defined in the ARM V4 Architecture
Reference manual (long multiplies, half word load and stores,
half word/byte signed loads).
Added support for the ARM810 IMB architecture defined SWIs.
Fixed bug in calculating some immediate constants.
Added support for the wfs, rfs, wfc, rfc instructions
Added support for the floating point compare instructions
Added ldf, stf, ldc and stc instructions.
Fixed mis-disassembly of some msr/mrs instructions.
The ldm and stm instructions will modify the direction identifier to
use the stack variations if the base register is r13.
variant of the CG4 (the one with the AMD colormap DACs). This has
been tested only on the "Type B" H/W at this point (Brooktree DACs).
Thanks to Ezra Story and Scott Ellis for the "Type A" support.
some guesses for the machines that have two of these buggers (I don't have
such a machine). This driver is a copy of the sparc/alpha esp with a
minimum of changes--after we get it performing a bit more respectably,
we should see about re-normalizing the sources.
- 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
second on Sun4m machines. Although this was in the noise of the unstable
Sun clock crystals before, the discrepancy amounted to about 100 ppm, and
thus made NTP perform poorly. NTP now works happily on my SS20...