RFC: [MIPS] Add an option to disable ldc1/sdc1

Maciej W. Rozycki macro@codesourcery.com
Fri Feb 15 01:23:00 GMT 2013

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:


-- 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.


More information about the Gcc-patches mailing list