Exception processing for MIPS R4000/__mips==3?

[Bruce Robinson]

Hello Joel,

Thanks for replying! I was hoping you would have some input on these issues.
I do have a build of the ticker sample running on a mips 3 target with the
standard MIPS exception handler. At least until it hits the breakpoint on
exit. I need to setup GDB and do further testing in a debugging mode. I'm
still trying to resolve the best way to support the various MIPS build
options. Your reply gave me the direction I needed. Please read my additions
below and let me know if you agree on this solution.

Greg, I'm very interested in your input also. By the way, I'll be happy to
send you my code changes at any point, but they're all related to mips 3, so
we might as wait until I have a complete solution.

Bruce

> -----Original Message-----
> From: Joel Sherrill <joel at OARcorp.com>
> [mailto:joel.sherrill at OARcorp.com]
> Sent: Saturday, July 24, 2004 7:23 AM
> To: Bruce Robinson
> Cc: rtems-users at rtems.com
> Subject: Re: Exception processing for MIPS R4000/__mips==3?
>
>
> 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.
>

OK, now I get it! You set the desired compiler options with CPU_CFLAGS in
the rtems-4.6.0/make/custom/<BSP>.cfg file, and then the RTEMS code is
conditionally built using the cpp predefines that result. Is this the
preferred way to implement processor dependent build options in RTEMS? If
that's the case, these are the MIPS compiler command options we're talking
about:

 -mips1 or -mips3  (R3000 or R4000 hardware)
 -mgp32 or -mgp64  (32 bit or 64 bit general purpose registers)
 -mfp32 or -mfp64  (16 or 32 floating point registers)
 -EB or -EL        (Big Endian or Little Endian)

I know I haven't mentioned the Endian option, but I think this one needs to
be supported also. Here are the resulting predefines for each of the flags:

 -mips1  =>  __mips=1
 -mips3  =>  __mips=3
 -mgp32  =>
 -mgp64  =>  __mips64
 -mfp32  =>  __mips_fpr=32
 -mfp64  =>  __mips_fpr=64
 -EB     =>  MIPSEB, _MIPSEB, __MIPSEB, __MIPSEB__
 -EL     =>  MIPSEL, _MIPSEL, __MIPSEL, __MIPSEL__

Joel, I think you might have tried -mgr32 by mistake. That may be why you
didn't see the resulting flag change. The -mips3 option appears to set
__mips64 and __mips_fpr=32 as defaults, but this isn't consistent with the
GCC documentation which says -mfp64 is the default with -mips3.

So in the case of mips 3, the code in cpu_asm.S should be built based on the
__mips, __mips64, and __mips_fpr flags from GCC. If __mips64 is defined, the
general purpose registers should be treated as 64 bits. If __mips_fpr equals
64, save and restore the additional 16 floating point registers. The __mips
flag can be used to select which instructions are available to use. For
setting the desired memory format (big or little endian), the definition of
CPU_BIG_ENDIAN and CPU_BIG_ENDIAN in cpu.h should be based on the __MIPSEB
or __MIPSEL predefines. Implementing this will allow MIPS builds to be
configured to best match the application needs using the <BSP>.cfg file
settings.

Let me know if this seems reasonable, and I'll start working on the code.