11:32 Uto, 07.04.2020. Philippe Mathieu-Daudé <phi...@redhat.com> је написао/ла: > > On 4/7/20 11:23 AM, Philippe Mathieu-Daudé wrote: > > On 4/7/20 10:35 AM, Peter Maydell wrote: > >> On Tue, 7 Apr 2020 at 00:55, Philippe Mathieu-Daudé <f4...@amsat.org> > >> wrote: > >>> > >>> Using the BC1ANY4F instruction with a 24Kf core (MIPS32R2 > >>> & ASE_MIPS16) we get: > >>> > >>> $ echo -ne '\x03\x20\xf8\x09EEEE' > cop1x.bin > >>> $ qemu-system-mipsel -bios cop1x.bin > >>> unknown branch 0x13000 > >>> Aborted (core dumped) > >> > >>> This is because this COP1X instruction generates a Reserved > >>> Instruction when used with this core, however we are in a delay > >>> slot, and exceptions in delay slot are architecturally unpredictable. > >>> > >>> Core dumps confunse users. Instead, report a friendlier error message: > >>> > >>> $ qemu-system-mipsel -bios cop1x.bin > >>> qemu-system-mipsel: Exception in delay slot is UNPREDICTABLE > >> > >> UNPREDICTABLE behaviour should not in QEMU include > >> causing QEMU to exit. You can log it with LOG_GUEST_ERROR > >> if you like but you should do something plausible (ideally what > >> some bit of real hardware does when this situation happens). > > > > OK. I have no clue how real 24Kf deals with it - I don't own one -, it > > is not in my list of interests (and my list of interests - which I can > > reproduce - is not modeled in QEMU). > > > >> > >> PS: does MIPS use the "UNPREDICTABLE" terminology? I > >> thought it was an Arm-ism, but maybe it's caught on more widely. > > > > At least it appears in my MIPS32 ISA Vol II (Revision 0.95) copy from 2001: > > > > 1.2 UNPREDICTABLE and UNDEFINED > > > > 1.2.1 UNPREDICTABLE > > UNPREDICTABLE results may vary from processor implementation to > > implementation, instruction to instruction, oras a function of time on > > the same implementation or instruction. Software can never depend on > > results that are UNPREDICTABLE. UNPREDICTABLE operations may cause a > > result to be generated or not. If a result is generated,it is > > UNPREDICTABLE. UNPREDICTABLE operations may cause arbitrary exceptions. > > UNPREDICTABLE results or operations have several implementation > > restrictions: > > • Implementations of operations generating UNPREDICTABLE results must > > not depend on any data source (memory or internal state) which is > > inaccessible in the current processor mode > > • UNPREDICTABLE operations must not read, write, or modify the contents > > of memory or internal state which is inaccessible in the current > > processor mode. For example, UNPREDICTABLE operations executed in user > > mode must not access memory or internal state that is only accessible in > > Kernel Mode or Debug Mode or in another process > > • UNPREDICTABLE operations must not halt or hang the processor > > > > 1.2.2 UNDEFINED > > UNDEFINED operations or behavior may vary from processor implementation > > to implementation, instruction to instruction, or as a function of time > > on the same implementation or instruction. UNDEFINED operations or > > behavior may vary from nothing to creating an environment in which > > execution can no longer continue. UNDEFINED operations or behavior may > > cause data loss. > > UNDEFINED operations or behavior has one implementation restriction: > > • UNDEFINED operations or behavior must not cause the processor to hang > > (that is, enter a state from which there is no exit other than powering > > down the processor). The assertion of any of the reset signals must > > restore the processorto an operational state > > > > Then: > > > > Jump and Link Register (JALR) > > > > Processor operation is UNPREDICTABLE if a branch, jump, ERET, DERET, or > > WAIT instruction is placed in the delay slot of a branch or jump. > > > > --- > > > > On Vol I Rev 6.01: > > > > 5.3.2.1 Control Transfer Instructions in Delay Slots and Forbidden Slots > > > > In MIPS architectures prior to Release 6. if a control transfer > > instruction (CTI) is placed in a branch delay slot, the operation of > > both instructions is UNPREDICTABLE. In Release 6, if a CTI is placed in > > a branch delay slot or a compact branch forbidden slot, implementations > > are required to signal a Reserved Instruction exception. > > Which also means this patch is incorrect for CPUs implementing the > Release 6 (which I'm not familiar with). > > > > > The following instructions are forbidden in branch delay slots and > > forbidden slots: any CTI, including branches and jumps, ERET, ERETNC, > > DERET, WAIT, and PAUSE. Their occurrence is required to signal a > > Reserved Instruction exception. > > > > 5.3.2.2 Exceptions and Delay and Forbidden Slots > > > > If an exception or interrupt prevents the completion of an instruction > > in a delay slot or forbidden slot, the hardware reports an Exception PC > > (CP0 EPC) of the branch, with a status bit set (StatusBD) to indicate > > that the exception was for the instruction in the delay slot of the branch. > > By convention, if an exception or interrupt prevents the completion of > > an instruction in a branch delay or forbidden slot, the branch > > instruction is re-executed and branch instructions must be restartable > > to permit this. In particular, procedure calls must be restartable. To > > insure that a procedure call is restartable, procedure calls that have a > > delay slot or forbidden slot (branch/jump-and-link instructions) should > > not use the register in which the return link is stored (usu-ally GPR > > 31) as a source register. This applies to all branch/jump-and-link > > instructions that have both a slot (delay or forbidden) and source > > registers, both for conditions (e.g., BGEZAL or BGEZALC) or for jump > > targets (JALR). > > > > --- > > > > I would have expected the behavior match the UNDEFINED description, as > > Yongbok Kim commented here: > > https://bugs.launchpad.net/qemu/+bug/1663287/comments/3 > > > > branches in a delay slot is "undefined" in the pre-Release > > 6 architecture. MIPS architectre release 6 defines to signal > > Reserved Instruction exceptions for such cases. > > > > But it really appears as UNPREDICTABLE. >
Folks, Thanks for everyone involved, esp. Philippe for devising the proposal and citing the manual about UNPREDICTABLE meaning, but I think this is too late to fix it in 5.0 (too risky), so let's talk about it in 5.0+. Yours, Aleksandar
