On Thu, 4 Dec 2014, David Daney wrote: > > GAS will happily schedule any instruction into a branch delay slot as > > long as the instruction is not architecturally forbidden there (e.g. > > ERET), there is no data dependency with the branch that would affect the > > result produced and the instruction is not an explicit exception trap > > operation (BREAK, SYSCALL, TEQ, etc.). For some reason, unknown to me all > > MT ASE instructions are disallowed too. Anything else -- free to go in! > > > > Of course instructions can be scheduled into branch delay slots manually > > too, in handcoded assembly, and that has to continue working. > > > > It is not difficult to also emulate the trapping instructions. In order to > move forward, I will implement the trapping instructions in my emulator for > the next patch. I'd be more concerned about getting the more exotic instructions or cases right (did you get MADDU right for SmartMIPS processors and set the ACX register on them?) -- how do you propose to validate and regression-test the emulator in a reproducible manner? The combination of the rare case of an instruction being placed in an FP branch delay slot and the rarity of some instructions themselves makes me scared of bugs lurking there forever and occasionally biting people -- who may not be aware that software emulation is involved let alone be capable to track them down -- in the most frustrating way. To say nothing of the infinite amount of effort to maintain the emulator associated with adding architectural and vendor-specific instructions. See how much effort has been put into QEMU and still it does not get all the MIPS instruction set bits right. Maciej
