This is the mail archive of the
mailing list for the binutils project.
RE: Macro expansion on MIPS
>> -----Original Message-----
>> From: email@example.com
>> [mailto:firstname.lastname@example.org] On Behalf Of Smets, Jan (Jan)
>> Sent: Tuesday, October 04, 2011 7:33 PM
>> To: email@example.com
>> Subject: Macro expansion on MIPS
>> Is there a way to disable macro expansion on MIPS? More
>> specific the replacement of 64bit instructions into two 32bit ones.
>> I'm using the O32 ABI, and I have code that uses some
>> (inline) assembly with 64bit instructions. We can not easily
>> switch to N32. (Long-term project)
>> For example, sd $a0, 0($sp) gets replaced by sw a0,0(sp)
>> + sw a1,4(sp).
>> The assembler only generates a warning when the maco expands
>> in a branch delay slot. When .set noreorder + .set nomacro
>> are used, the assembler prints a warnings for every 'replacement'.
>> My code base is -very- large, so I can not easily add 'set
>> .mips3' to every assembly block there is. Is there an easy
>> way to find all places where this expansion is happening, ie,
>> turn on 'nomacro'.
>> Or, is there something wrong with my new toolchain? (I'm
>> trying to migrate from gcc34/binutils2.16.1 to
>> gcc46/binutils2.21.52) Are there any other options I missed ?
> -----Original Message-----
> From: Paul_Koning@Dell.com [mailto:Paul_Koning@Dell.com]
> Sent: woensdag 5 oktober 2011 2:58
> To: Smets, Jan (Jan); firstname.lastname@example.org
> Subject: RE: Macro expansion on MIPS
> Have you considered O64? It's like O32 except with 64 bit
> registers and 64-bit operations. It gives you much of the
> benefits you'd get from N32 with a lot less effort. We've
> used it for years with excellent results.
We have a very customized VxWorks 5 and a lot of in-house software. It would be too much work to switch entirely to a new ABI in a few weeks/months. So I really want to get everything building and running with the new toolchain. 64bit pointers are too much overhead for us, so we will likely go to N32 in the near future. But first things first, and that's a new toolchain.
I would be happy with the assembler telling me where it's changing 64bit instructions into two 32bit ones, so that I know where to '''fix''' the code.