[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Aha!




>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 9/1/00, 11:45:23 AM, "Christopher C. Chimelis" <chris@debian.org> wrote 
regarding Aha!:


> Found out something interesting.  I was trying to figure out why
> gcc/fold-const.c wouldn't assemble properly and found a set of
> command-line options where it would.

> Some background, I decided to add '-save-temps -v' to gcc's options while
> compiling.  What it showed command-wise was exactly what I expected, so
> I'll omit that stuff.  I then tried hand-running gas with the options 
that
> gcc was passing it on fold-const.s. Here's the errors I got:

> # as -EB -v -KPIC -o fold-const.o fold-const.s
> fold-const.s: Assembler messages:
> fold-const.s:27290: Error: Branch out of range
> fold-const.s:27329: Error: Branch out of range
> fold-const.s:27334: Error: Branch out of range
> fold-const.s:28748: Error: Branch out of range
> fold-const.s:28861: Error: Branch out of range

> Ok, I tried a few things including looking directly at the assembly
> generated by cc1 (despite not having any MIPS asm references around, it
> looked ok...looks like it was supposed to be using jumps to the branches
> that gas was saying was out of range).

> I then hit the gas docs and tried various MIPS-specific options with
> eventual success.  Turns out that adding any of the -mips? options other
> than -mips1 allows it to assemble correctly.  For the uninformed, here's 
a
> breakdown on those options:
>       -mips1 = generates code for the R2000 and R3000 processors
>       -mips2 = generates code for the R6000 processor
>       -mips3 = generates code for the R4000 processor
>       -mips4 = generates code for the R8000 and R10000 processors


> It seems that, when binutils is configured for the mips-unknown-linux-gnu
> target, it assumes that -mips1 is the default, apparently.  This is
> probably for maximum compatibility.  Since I don't have any reference
> manuals on the generations of MIPS processors, I don't really know the
> differences yet between all of these families, but it appears that, 
either
> the R2000/R3000 processors cannot handle these specific jumps for some
> reason OR (most likely) there is a bug in binutils wrt -mips1 support.

> Can someone educate me on the differences between the families of
> MIPS processors or point me towards some technical docs?  I can probably
> isolate this problem in binutils if I had more to work with.  Also, this
> may turn up a bug in gcc as well (who knows at this point...I'm too new 
to
> this arch to really know what may be involved).  In the meantime, I'm
> going to see if I can target binutils and gcc towards the R4x00 that's in
> this indy and go from there.

The mips1/2/3/4 are different mips instruction set architectures.  
Processors that are mips4 compliant, for example, also have instruction 
compatibility with the previous  architectures -- mips1/2/3.  Thus, mips3 
doesn't mean R4000, but the R4000 might be a mips3 cpu (the 5000 is 
mips4).

It would be nice to get gcc/binutils fixed for all ISAs, but if you have 
to target a certain ISA, start with mips3.  Most newer processor are 
either mips3 or mips4 cpus, so that would be of the most benefit to 
mips-linux, imho.

If you're interested in mips in general, the best book out there, in my 
opinion, is 'See Mips Run' by Dominic Sweetman.

Pete



Reply to: