This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: MIPS16: AS wouldn't assemble gcc output.


   From: "Dmitri Makarov" <dim@windriver.com>
   Date: Thu, 2 Mar 2000 17:50:54 -0800

   > Actually, it really is a PC relative load from a different section.
   > The instruction is in the section
   >     .gnu.linkonce.t.__vc__t9RWTBitVec1i17Ui
   > I don't know what the section the string is in.

   I wouldn't completely agree.  LA $4, addr insn itself is supposed to be a macro
   that for MIPS ISA unfolds into 2 insn lui $at, hi (addr) and addi $4, $at, lo (addr)
   But whether this is PC realtive load on MIPS16 depends on implementation of
   LA macro.

For the mips16, la is an alias for addiu.

   I would assume that addr (32-bit value) is placed right before the function
   that being assembled and thus the whole issue of sections would be irrelevant.

The assembler could do that.  It would require additional work to know
where the start of a function was.  Instead of doing that, I arranged
to keep the assembler simple, and have gcc do the work.  The GNU
approach in general has been to put the intelligence in the compiler
rather than the assembler.  The compiler generally knows a lot more.

Also, the point of the mips16 is to take up the least possible amount
of space.  Your suggestion would require an additional 4 bytes.
Trivial, yes, but when the point is to require less space, and when
there is a perfectly good alternative (putting the string constant in
the same section), there is no reason to waste those 4 bytes.

   > gcc is supposed to avoid this.  It is supposed to put the string
   > constant in the same section as the function.  I'm not sure why that
   > isn't working in your case.

   Maybe I could give something very approximate explanation, without actually
   explaining the reasons for the compiler behaviour.

I wasn't really asking for an explanation.  I wrote most of the
original mips16 port of the compiler, and I was explaining how I
intended it to work.

Ian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]