linux-mips
[Top] [All Lists]

R2300 (not the hay baler)

To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: R2300 (not the hay baler)
From: Paul Burton <paul.burton@imgtec.com>
Date: Tue, 19 Nov 2013 11:07:22 +0000
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
Hello,

Does anyone still care about the R2300? I ask because I'm working on
the FP context switching code & noticed that I'm pretty sure the
fpu_save_single & fpu_restore_single macros used only from
r2300_switch.S are broken. They store each 32 bit value at the start
of the location of the 64 bit FP registers context in memory, which I
believe:

1) Won't work for odd indexed FP registers with the FPU emulator,
   ptrace or other code which assumes that 32 bit FP data is held in
   the even-indexed 64 bit FP register context.

2) On big endian systems the 32 bit values will get saved to the most
   significant bits of the 64 bit context which I imagine will cause
   yet more problems.

It seems like the only changes to r2300_switch.S for a *long* time have
been to keep it in sync with r4k_switch.S & the CPU is old enough that
all I get when I google for it is information about some hay baler.

In short: does anyone care if I just submit a patch removing the R2300
code instead of blindly attempting to fix it up?

Thanks,
    Paul


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