mps32 was Re: upcoming snapshot and 4.6.2

[Ralf Corsepius]

On Wed, 2004-09-29 at 21:21, Jay Monkman wrote:
> On Tue, Sep 28, 2004 at 06:11:38PM +0200, Ralf Corsepius wrote:
> > Your patches rely on "#define __mips32". Current mips-rtems-gcc only
> > supports and implies -mips1.
> 
> I'm confused. I can't find any reference to "__mips32" in any code I
> have. I see conditionals with "__mips == 32", but that's it. Are
> we looking at the same code?
Probably not. I am looking at
* code as being produced by gcc-3.4.3pre
* cpukit/score/cpu/mips/* from RTEMS-CVS-trunk 
* the patch attached to PR601

>  I just checked the patch attached to
> PR601, also.
>
> > => If I understand correctly, you assume using gcc -mips1 -D__mips32.
> 
> I don't think so. For the MIPS32 BSP I've got, I use "gcc -mips32"
OK. Then you are compiling RTEMS using the mips32 ISA and __mips32
implicitly being defined by gcc.

However, current mips-rtems*-gcc doesn't have a -mips32 compiled
multilib variant.

This means, gcc -mips32 implies using the default multilib variant of
GCC's internal libs (libc, libgcc, libstdc++ etc.). These are -mips1
compiled.

In the end you are linking libraries having been compiled with different
ISAs.

[Add -c to the linker invocation when linking applications and I'd
expect you to see gcc linking against /opt/rtems*/mips-rtems/lib/libc.a.
This libc is -mips1 compiled.]

So the actual question is: Is the mips32 backward compatible to the
mips1?
I know too little about the mips architecture to be sure if these two
ISAs are compatible.

If it is, there is nothing wrong with it, it is just suboptimal (Using a
i386-compiled libc with i686-compiled kernels/apps), if not, things can
be subtly broken ("using AMD instructions on Intel processors") and you
just might have been lucky not having tripped an incompatibility, yet.
I simply don't know.

Additional problems can occur if using a multilib'ed cpukit. With
current mips-rtems-gcc, you then will be using a  -mips1 compiled
cpukit, but -mips32 compiled BSP code. If -mips32/-D__mips32 in
comparision to -mips1/-D__mips1 changes something related to
stack-frames or cpu-contexts, you'd probably end up in a disaster.

> > So, what I actually was asking is: Does the mips-RTEMS code with your
> > changes applied support -mips32?
> 
> It seems to.

Fine. This is what I wanted to know. It at least is an indication that
the mips32 patches might be ready for full -mips32 support.

I think we should try to add a mips32 multilib variant to rtems-gcc.

>  To build for the AU1500 (MIPS32 CPU), I have to use -mips32
> From csb350.cfg:
>      CPU_CFLAGS=-mips32 -G0 -msoft-float

OK, "-mips32 -msoft-float" ... so, you are actually linking against
/opt/rtems*/lib/mips-rtems*/lib/soft-float/*.a
(mips1 w/ soft-float)

Ralf