Maciej W. Rozycki wrote: > > 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=2012 0615234641.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.
The kernel emulation can help, but the performance is not great (as Ralf pointed out). So, this compiler workaround may have its advantages. > > 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 It is still good for 32-bit MIPS Linux targets. Right? > -- 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. Thanks for this point! I tested the patch and it cannot work with -mabi=32 -mfp64. Probably we can limit the scope of the patch to 32-bit MIPS targets with 32-bit FPU. > > 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. > I know this, but it's very hard to educate people and let people admit it's not CPU's fault, when same software can run on other architectures. Thanks a lot for your inputs! Regards, Chao-ying
