blob: d2b8dc907dfdcc635c976f99852443fce7caec4a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, so I'm trying to classify this bug report for QEMU. Let's read through it carefully.
The problem is about an incorrect order when handling `fmovem` instructions involving multiple FPU control registers on the m68k architecture. The manual specifies that these registers should be moved in a specific sequence: first the floating-point control register, then the status register, and lastly the instruction address register. However, QEMU is currently processing them in reverse order.
The user provided a code snippet showing changes to `translate.c`. In this diff, they're modifying loops that handle reading or writing these registers. The original code was iterating from higher indices down to lower (like i=2 to 0), which might have been causing the reversed order. The fix adjusts the loop direction and mask handling to ensure the correct sequence.
So, considering the categories: instruction, syscall, runtime. This issue is about how QEMU handles a specific instruction (`fmovem`) with certain registers. It's not related to system calls or general runtime errors; it's an error in executing an instruction as per the architecture manual. Therefore, this falls under the 'instruction' category.
</think>
The bug report describes an issue with handling a specific instruction (`fmovem`) incorrectly. This is classified as an instruction-related problem.
instruction
|