mps32 was Re: upcoming snapshot and 4.6.2

gregory.menke at gsfc.nasa.gov gregory.menke at gsfc.nasa.gov
Tue Sep 28 17:17:31 UTC 2004


Ralf Corsepius writes:
 > On Tue, 2004-09-28 at 17:14, gregory.menke at gsfc.nasa.gov wrote:
 > > Ralf Corsepius writes:
 > >  > 
 > >  > The essential question to me is:
 > >  > Is -mips32 compiled code compatible to -mips1 compiled code?
 > >  > 
 > > 
 > > IIRC, the changes are principally #ifdefs to influence cpu_asm related
 > > register stuff, not gcc code generation issues.  The mips32 question
 > > arises infrequently enough that I keep forgetting the details.
 > AFAIS from the patches in GNATS, you remember correctly.
 > 
 > >   I
 > > think the upshot is -mips1 or -mips3 is still required to make gcc do
 > > the right stuff, mips32 is there to force R4000 registers in cases
 > > where they're required.  Anyone, please correct me if I'm
 > > mis-remembering.
 > Well, I suspect a compatibility problem between "gcc -mips32" rsp
 > "-arch=mips32" and your patches.

I think this means we have an unfortunate coincidence in naming.  

 
 > Your patches rely on "#define __mips32". Current mips-rtems-gcc only
 > supports and implies -mips1.
 > => If I understand correctly, you assume using gcc -mips1 -D__mips32.
 > 
 > "gcc -mips32" rsp. "gcc -arch=mips32" implicitly changes code generation
 > to mips32 and #defines __mips32 rsp. #defines __mips32__.
 > 
 > So, what I actually was asking is: Does the mips-RTEMS code with your
 > changes applied support -mips32?

The mips32 people need to weigh in on this one.  My understanding was
that normal gcc code generation was sufficient- meaning no -mips32.


 > If so, it would be worth considering adding a -mips32 multilib variant
 > to gcc (at least for rtems4.7), if not, I'd prefer to see your patches
 > changed to not using -D__mips32, because this can be ambiguous and might
 > conflict with the flags being implied by "gcc -mips32"
 > 
 > (All defines starting with double underscores are reserved)

Agreed.  Since its half done with PR601, would it be reasonable to get
all the __mips32 stuff in, then change it all to something else?


 > 
 > PS: All PM, I tried send to your GSFC email address bounce. Until now
 > I've tried 3 different sending addresses (even trying to notify your
 > postmaster fails). I'd therefore suggest you to refrain from using your
 > GSFC email address in public in future, because people can't reply to
 > you. Sorry, but I feel saying this is inevitable.

I was hoping it was a transient problem.  I just called the GSFC
networking people, they would like a copy of the bounce.  If you could
email it w/ headers to "gregm-news at toadmail.com", I'll forward it to
them and we can do some diagnostics on this end.  Apparently, this
shouldn't be happening....  Sorry for the bother.

Gregm





More information about the users mailing list