On Tue, Nov 19, 2013 at 11:07:22AM +0000, Paul Burton wrote: > 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. Note that much of that code has changed for 3.13 and the new code may or may not have inherited this bug. > 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? Linux/MIPS is a product of the post-R3000 era - but Maciej (on cc) is doing his best to keep it alive and going on DECstations, including R2000 and R3000 based ones. DECstations are little endian and all of them have a R2010 rsp R3010, that is have hardware floating point. I myself have an R3000-based workstation, a clone of a MIPS RS3230 (I think) sitting on my floor and waiting to be reactivated. It's still running RISC/os. Ralf
