Exception processing for MIPS R4000/__mips==3?

[Joel Sherrill <joel@OARcorp.com>]

Bruce Robinson wrote:
> Hello Friends,

Greg Menke answered this pretty thoroughly so I will not address
everything.

> 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.

gcc has a -mgr32 flag for the mips which appears to be what you would
specify when you want to do this.  Is this right?

If so, then gcc SHOULD define something to indicate that you want
this configuration.  Unfortunately, I just checked and it doesn't
seem to.  These commands dump the cpp predefines based upon the
arguments and they are the same.

/op/rtems-4.6/bin/mips-rtems-gcc -mips3 -mgr32 -dM -E - </dev/null
/opt/rtems-4.6/bin/mips-rtems-gcc -mips3 -dM -E - </dev/null

What gcc flags would you use to specify this combination?

Greg is right in that parsing the gcc flags in 1 place
into a smaller and hopefully easier to understand set
for RTEMS use could simplify things.  The mips combinations
are hard to track.

> 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.

The big different between the old and new mips code is that RTEMS now
takes the interrupts/exceptions itself.  In the above case, the
interrupt/exception would need to be routed to PMON with the
frame correct.

We used generic MIPS books ans See MIPS Run for help on CPU models
we didn't have.  If it isn't right, it just needs to be fixed.  Run
fixes through Greg and he can doublecheck them on the R3000.

> 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?

The first level exception handler actually routes through a pluggable 
routine so you might be able to do already.

THe proliferation of duplicated code for the PowerPC exception code is
a big drawback of that approach.  Maintenance can be painful.  What
precisely do you want to override?

> 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.

Those sounds like the books weren't that much help. :)

Run fixes through Greg and he can file PRs.  The issues in (4) sound
like obvious bugs that just need to be fixed.

--joel


> Thanks in advance for any feedback!
> Bruce
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985