On Thu, 14 Feb 2013, Richard Sandiford wrote: > What about 64-bit targets? We can sometimes access doubles using GPRs, > so on 64-bit targets we could end up using LD and SD to access a double > even when this option disables LDC1 and SDC1. I think we'd need to > patch the move patterns as well.
As far as Linux is concerned -- which from the context of this consideration I infer is the case -- there is no issue, because unless an app has explicitly requested this feature to be disabled, with the use of the sysmips(2) FIXADE API (which of course hardly any does), all address error exceptions triggered by an unaligned memory access made with a CPU instruction are trapped by the kernel and the access emulated. However no such accesses are emulated when made with a coprocessor instruction, whether the FPU or CP2 or the legacy CP1 and CP3 units as supported by earlier processors. There was once a proposal to emulate FPU instructions as well, posted on the linux-mips mailing list here: http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20120615234641.6938B58FE7C%40mail.viric.name -- but the MIPS/Linux maintainer rejected the idea. I have cc-ed Ralf on this reply in case he wanted to add something. Of course an option to GCC to disable any such instructions may have some value to some people -- for bare-iron targets if nothing else -- but I fear this is going to end up with a lot of hassle with 64-bit ABIs or even just 64-bit FPU (-mabi=32 -mfp64) as individual halves of 64-bit registers are not addressable in the MIPS architecture (e.g. there's no LWHC1 instruction), so you'll need to use scratch registers. Which is why I think any resources put into this effort would better be used to clean up such broken code and, perhaps more importantly, to educate people to write their programs properly in the first place. Writing portable code is really not a big deal, you just need to remember all the world is not x86 and apply a few simple rules. Maciej
