Exception processing for MIPS R4000/__mips==3?

[Bruce Robinson]

Hello Friends,

I'm working on a BSP for a Toshiba TX4925 MIPS processor. I've run into some
problems in the exception handling code for the MIPS R4000 (__mips==3) under
RTEMS4.6.0. Maybe some of the MIPS contributors could give me some feedback
on the following issues. Do I have some valid points, or am I totally off
base? Have these issues already been debated and decided?

1. In RTEMS 4.5.0, defining CPU_R3000 and CPU_R4000 selected the MIPS
hardware implementation, and defining __mips=1 and __mips=3 selected whether
you used 32 bit or 64 bit registers respectively. There was a close
correlation between __mips==3 and the GCC -mips3 compiler option.

In RTEMS 4.6.0, defining __mips=1 and __mips=3 selects R3000 or R4000
hardware respectively, and also selects 32 bit or 64 bit registers
respectively. But what if you have R4000 hardware, and want to use 32 bit
registers for performance? This new arrangement does not allow for this. It
seems to me this is one design change that should be reconsidered.

2. In RTEMS 4.6.0, for R3000/mips=1 the SR_IEC status flag is used to
enable/disable interrupts. For the R4000/mips=3 the SR_EXL flag is used in
combination with the SR_IE flag. Using the SR_EXL flag for this purpose
appears to be incompatible with the exception handling by a resident debug
monitor. Here's one situation I'm running into: I have an evaluation board
running PMON debug monitor, I load a build of RTEMS into memory and use PMON
to set a breakpoint in a task. If interrupts are disabled (SR_EXL set) when
I hit the breakpoint, PMON takes the exception but fails to get the right
breakpoint address.

The way I understand the SR_EXL flag, it should be used solely as a hold off
of interrupts inside the exception handler. For the R4000, the SR_IE flag
can be used by RTEMS to enable/disable interrupts, as is done for the R3000.

Even if there is some justification for using the SR_EXL flag for this
purpose, I think the current code needs further review. It appears that
SR_EXL is being set to enable interrupts, when it should be cleared. See
#define _INTON (SR_EXL | SR_IE) in cpu.h.

3. The MIPS exception handler is shared by all MIPS BSP's. In trying to run
RTEMS in conjunction with a debug monitor that may be resident, it would be
desirable to have an exception handler that can be tailored to the BSP. This
appears to have been done for some of the PowerPC ports. Does anybody else
see the benefit of supporting a BSP or processor specific exception handler
in the libbsp or libcpu directories?

4. A few problems in cpu_asm.S for __mips==3:

4a. "#define NOP <blank>" causes assembler warnings about instructions in
delay slots. I don't think this "deleted" nop is correct.

4b. The _CPU_Context_restore_fp_from_exception routine uses "*4" to
calculate address offsets. I think it should use "*F_SZ".

4c. _CPU_Context_save_fp_from_exception and
_CPU_Context_restore_fp_from_exception routines should use sdc1 and ldc1
instructions for __mips==3.

I'll be happy to provide my proposed fixes to rtems.org, but I need some
guidance on the best way to do that.

Thanks in advance for any feedback!
Bruce