[Top] [All Lists]

Re: [PATCH] MIPS: Add emulation for fpureg-mem unaligned access

To: "Maciej W. Rozycki" <>
Subject: Re: [PATCH] MIPS: Add emulation for fpureg-mem unaligned access
From: Lluís Batlle i Rossell <>
Date: Mon, 30 Jul 2012 21:47:54 +0200
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
References: <> <> <> <> <> <>
User-agent: Mutt/1.5.20 (2009-06-14)
Hello Maciej,

On Wed, Jul 11, 2012 at 01:05:04AM +0100, Maciej W. Rozycki wrote:
> On Wed, 20 Jun 2012, Lluís Batlle i Rossell wrote:
> > > > Well, I think I take my words back. Handling the ldc1/sdc1 cases in 
> > > > MIPS32 is
> > > > tricker than I thought first, because I can't use ldl/ldr or sdl/sdr 
> > > > there.
> > > > Given my ability with mips assembly, I leave the patch as is.
>  I suggest that for 32-bit kernels you simply reuse the existing snippets 
> from that function and handle ldc1/sdc1 with a pair of lwl/ldr or swl/swr 
> pairs ordered as appropriate for the endianness selected -- that should be 
> fairly easy.

Hm I still don't understand well enough how to do that. Would I need to get some
aligned memory (a stack automatic variable for example), copy the double word
there with proper endianness, and then call again ldc1? (similar for sdc1)

>  Also regardless of that, please make sure that your code handles the two 
> possible settings of CP0 Status register's bit FR correctly, as the 32-bit 
> halves of floating-point data are distributed differently across 
> floating-point registers based on this bit's setting (check if an o32 and 
> an n64 or n32 program gets these values right).

Hm I'm failing to find in the mips-iv.pdf how to check that FR bit, although I
see it mentioned there. Sorry.

> > As Jonas reported, I think that maybe I should rework the patch for it to 
> > emit
> > sigbus instead of sigill on ldc1,ldc1 for mips32. Do I understand it right?
>  Have you checked your code against a non-FPU processor (or with the 
> "nofpu" kernel option) too?

No. Would in that case the processor have the fpu disabled? I understand that
the code path is called only in a particular case of 'unaligned access'

Thank you for your comments.


<Prev in Thread] Current Thread [Next in Thread>