[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
mps32 was Re: upcoming snapshot and 4.6.2
- Date: Thu, 30 Sep 2004 05:05:22 +0200
- From: ralf_corsepius at rtems.org (Ralf Corsepius)
- Subject: mps32 was Re: upcoming snapshot and 4.6.2
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
This means, gcc -mips32 implies using the default multilib variant of
GCC's internal libs (libc, libgcc, libstdc++ etc.). These are -mips1
In the end you are linking libraries having been compiled with different
[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
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
(mips1 w/ soft-float)