Re: [PATCH v2] MIPS: Add basic R5900 support

[Fredrik Noring <noring@nocrew.org>]

Hi Maciej,

> > Unfortunately I haven't found such a switch. There is also a set of 128-bit
> > multimedia instructions to consider (GCC is perhaps unlikely to generate
> > those but assembly code is an option too).
> 
>  The usual minimal approach is to have compiler intrinsics implemented.

I sometimes make less than minimal programs, or unusual ones, or both. ;)

>  Virtually all 64-bit MIPS processors have the CP0.Status.UX bit, which 
> the Linux kernel keeps clear for o32 processes (CP0.Status.PX is currently 
> unsupported and is kept clear as well), which means that an attempt to use 
> any instruction that affects register bits beyond bit #31 will cause a 
> Reserved Instruction exception, and in turn SIGILL being sent to the 
> program.  

Would UX be bit 5 of CP0.Status? That bit is hardwired to naught according
to the TX79 manual (p. 4-16).

>  So any crash caused by the lack of handling of the upper bits is a result 
> of either a kernel bug or an issue with hardware.

R5900 does not seem to implement UX, SX, KX or PX.

>  Hmm, can you verify that no LWU instruction is present in the kernel 
> somewhere?

Sure, "mipsel-linux-objdump -d vmlinux | grep lwu" yields nil.

>  Can you add a diagnostic consistency check to the context restoration 
> code, i.e. all the macros called from RESTORE_ALL (in <asm/stackframe.h>), 
> such as a `break 12' (BRK_BUG) instruction if a register value is not 
> correctly sign-extended?  You can instead use one of the register trap 
> instructions (with the same BRK_BUG code), to avoid the need for a branch.  
> Make sure you don't clobber registers restored; you may have to use $k0 or 
> $k1 in places.  This will cause a kernel oops, which can then be examined 
> to track down a possible cause.

Given the R5900 patch I believe this can be done somewhat simpler, since
register access macros have been implemented in C (in this way the physical
registers become in some sense separated from the logical registers in the
kernel).

The transition from 128-bit registers to 64-bit registers was easy (in a
32-bit kernel) by changing the LONGD_{L,S} macros in asm.h from quadword
{L,S}Q to doubleword {L,S}D instructions, and changing pt_regs::regs[32]
from r5900_reg_t to unsigned long long. (The patch replaces LONG_* with
three variants: LONGD_*, LONGH_* and LONGI_*. It also forces LD and SD
via a ".set push/.set mips3/.set pop" combination like you outline below.)

The patch has full 64-bit registers accessible in C too, which is why I
propose to do the diagnostic consistency check in C. (Macros truncate to
32 bits everywhere in the kernel except for save/restore.)

>  GAS will prevent the use of any 64-bit instructions (which LWU is one of) 
> when the o32 ABI has been selected for assembly, however it can be 
> temporarily overridden by `.set' pseudo-ops, and also I haven't verified 
> if there isn't an issue with `-march=r5900' in GAS.

I'm using a BusyBox binary from the Debian-based Black Rhino distribution,
so I'm not entirely sure how it was compiled, and it might contain 64-bit
instructions that are not caught by the (unavailable) UX bit.

Fredrik