Is there any tool can generate MIPS ELF file?

Hi,

To my understanding, ll/bc can translate to any target machine code
that make cross-compiling easy.

$llc -march=mipsel -mcpu=mips64 test.ll
generate test.s(MIPS ASM)

There must be a tool turns test.s to mips ELF file to make this whole
thing done completely. What is it?

An assembler is the tool you're after. [And a linker if you want to have an executable in the end].

You can specify -filetype=obj to llc and you should get an object file. Note that llvm-mc is not an end-user tool but it should do the job you have asked as well i.e.,

llvm-mc -arch=mips64 =mcpu=mips64 -filetype=obj test.s -o test.o (this should generate test.o)

Regards,
Matheus

Hi Matheus,

   Thank you for your information! Do you known where do download MIPS
ABI/EABI document? Thanks in advance!

Could you be more specific about what ABIs are you after ? The reason I'm asking is that there are several ABIs available for Mips and only a few of them are supported by LLVM (o32, n32 and n64). There are several ABIs defined by GNU with very little documentation that describes them (EABI is one example).

We are aware that the available documentation and GCC disagree sometimes and given that GCC is the de-facto standard, LLVM tries to follow GCC's behaviour as close as possible.

As far as I know there isn't any link from Imagination Technologies' website that I can point you to w.r.t ABIs but there's documentation out there like:
https://dmz-portal.mips.com/mw/images/f/fe/MD00305-2B-ABIDESC-SPC-01.03.pdf // This is probably the best document as it compares the 3 most important ABIs. Note that it's an old document and needs some refactoring given that the implementation in GCC sometimes differs from the documentation.
http://math-atlas.sourceforge.net/devel/assembly/mipsabi32.pdf // O32
ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/MIPS-N32-ABI-Handbook.pdf //n32

Regards,
Matheus

Thank you very much for your information and documents!

Why Imagination Technologies do not offer the latest MIPS ABI document
download link just like the ISA docs? If they thought no much people
interested in that doc, they had to make greate effort on compiler
like GCC,LLVM by themself,then why GCC disagree with some MIPS ABI, it
should be freely designed by MIPS ABI designer and compiler backend
target implementation. Do I miss something?

Why Imagination Technologies do not offer the latest MIPS ABI document download link just like the ISA docs?

It's something we're considering to do and the documents should be available at some point in the [hopefully] not too distant future.

then why GCC disagree with some MIPS ABI, it should be freely designed by MIPS ABI designer and compiler backend target implementation.

I don't have a very good explanation to this question. The ABIs were implemented a long time ago and I can only guess at this point but I'd say that there were some misinterpretations of the spec and given the popularity of GCC, the implementation became the new standard and it's something that LLVM needs to cope with.

Regards,
Matheus

Why Imagination Technologies do not offer the latest MIPS ABI document download link just like the ISA docs?

It's something we're considering to do and the documents should be available at some point in the [hopefully] not too distant future.

then why GCC disagree with some MIPS ABI, it should be freely designed by MIPS ABI designer and compiler backend target implementation.

I don't have a very good explanation to this question. The ABIs were implemented a long time ago and I can only guess at this point but I'd say that there were some misinterpretations of the spec and given the popularity of GCC, the implementation became the new standard and it's something that LLVM needs to cope with.

There are a lot of MIPS ABIs.

o32, n32, n64 - These came from the SGI world for IRIX originally, but
were also adopted for linux and used in gcc for both.
o64 - Invented at Cygnus for 64-bit processors
eabi - Different one invented at Cygnus
meabi - Invented with MIPS and Cygnus (and possibly others) in the
late 90s as a new embedded abi.
And there's been at least one or two other ABIs since - I'm pretty
sure Imagination Technologies working up a new abi right now.

-eric

There are a lot of MIPS ABIs.

Yes, and we've discovered that there seem to be incompatible extensions to some of these ABI's too.

I'm pretty sure Imagination Technologies working up a new abi right now.

Not exactly. We're not working on any completely new ABI's but we are fixing a compatibility flaw between the O32 ABI and a (currently) unsupported extension that allows the efficient use of FR=1 mode (FPU with 64-bit registers). This is going to be important since MIPS32r6/MIPS64r6 will not have direct support for FR=0 mode (FPU with 32-bit registers). At the moment, this extension is available in all the tools and is enabled with -mfp64. Unfortunately, it is not possible to inter-link O32 and O32+fp64 code since they require the FPU to be in different modes. To fix the compatibility flaw, we are adding an O32 extension called fpxx (enabled with -mfpxx) which operates correctly in both FPU modes and is essentially O32 with some minor restrictions. O32+fpxx is ABI-compatible with O32 and O32+fp64 and can inter-link with either but not both at the same time (because they conflict with eachother). The intention is that as code is re-compiled, O32+fpxx will replace O32 and we will end up the mode requirements being either 'FR=1' or "don't care".

In case you're curious, the fpxx restrictions are:
* Use of mtc1, mfc1, lwc1, and swc1 on the upper 32-bits of a double precision value is not permitted.
* Some callee-saved registers are also treated as caller-saved.

There are a lot of MIPS ABIs.

Yes, and we've discovered that there seem to be incompatible extensions to some of these ABI's too.

:slight_smile:

I'm pretty sure Imagination Technologies working up a new abi right now.

Not exactly. We're not working on any completely new ABI's but we are fixing a compatibility flaw between the O32 ABI and a (currently) unsupported extension that allows the efficient use of FR=1 mode (FPU with 64-bit registers). This is going to be important since MIPS32r6/MIPS64r6 will not have direct support for FR=0 mode (FPU with 32-bit registers). At the moment, this extension is available in all the tools and is enabled with -mfp64. Unfortunately, it is not possible to inter-link O32 and O32+fp64 code since they require the FPU to be in different modes. To fix the compatibility flaw, we are adding an O32 extension called fpxx (enabled with -mfpxx) which operates correctly in both FPU modes and is essentially O32 with some minor restrictions. O32+fpxx is ABI-compatible with O32 and O32+fp64 and can inter-link with either but not both at the same time (because they conflict with eachother). The intention is that as code is re-compiled, O32+fpxx will replace O32 and we will end up the mode requirements being either 'FR=1' or "don't care".

In case you're curious, the fpxx restrictions are:
* Use of mtc1, mfc1, lwc1, and swc1 on the upper 32-bits of a double precision value is not permitted.
* Some callee-saved registers are also treated as caller-saved.

Well, this is definitely ABI breaking, so effectively a new ABI is what I meant.

Curious why an extension to o32 for this and not, for example, just using n32?

-eric

Well, this is definitely ABI breaking, so effectively a new ABI is what I meant.

I had the same initial reaction when it was first explained to me but it doesn't actually break the ABI compatibility. It's really a seamless migration. Suppose you have a big source base such as 32-bit Debian. All the packages are compiled for O32 so any package that uses the FPU requires FR=0 mode. Once O32+fpxx is in the compiler and becomes the default, the packages will be gradually rebuilt with O32+fpxx as the ABI. O32 and O32+fpxx are ABI compatible (I'll explain this in the next two paragraphs) so we can mix an O32+fpxx glibc and an O32 libavcodec as part of ffmpeg (the result being an O32 ffmpeg binary requiring FR=0 mode). Over time, more and more packages are rebuilt with O32+fpxx (through natural churn) and the source base becomes more and more FR mode independent. Sooner or later our previous example of glibc, libavcodec, and ffmpeg is entirely O32+fpxx and no longer requires any particular FR mode.

Earlier, I mentioned that O32 and O32+fpxx are ABI compatible but didn't explain it. We'll start with the 'Some callee-saved registers are also treated as caller-saved' change. In O32, the 32-bit values in $f20 - $f31 are callee saved. In O32+fpxx, the 64-bit values in even registers $f20 to $f30 are callee saved. In FR=0 mode, these definitions are equivalent since 'swc1 $f20, 0($base)' and 'swc1 $f21, 4($base)' modifies memory in the same way as 'sdc1 $f20, 0($base)'. We don't have to worry about the extra alignment restriction because the stack is 8-byte aligned. However, in O32+fpxx the odd registers $f21 to $f31 are _also_ caller saved in addition to being callee saved. In FR=0 mode, this means that these values are preserved by both the caller and the callee, but in FR=1 mode they are only preserved by the caller because in FR=1 mode 'sdc1 $f20, 0($base)' does not store any part of $f21. Hopefully that made sense to you, it's probably the hardest part of O32+fpxx to follow.

The one remaining difference between FR=0 and FR=1 is that reads/writes to/from the upper 32-bits of a double precision value can be done via odd registers in FR=0 mode, but must be done via dedicated instructions in FR=1 mode. For example, in FR=0 mode 'mtc1 $zero, $f21' zeros the upper 32-bits of the double-precision value in $f20. In FR=1, we would use 'mthc1 $zero, $f20'. To resolve this, O32+fpxx simply bans the exploitation of the fact that the odd registers are the upper 32-bits of the even registers. Both FR=0 and FR=1 must use 'mthc1 $zero, $f20'. The catch is that MIPS-II and MIPS32r1 don't have 'mthc1' and don't have the alternative available to the 64-bit ISA's (dmtc1) either. These two must use a sdc1/ldc1 sequence instead. It's unpleasant but the benefit of fixing the bigger issue and migrating to a world where code can run on both FR=0 and FR=1 without modification is seen to outweigh the cost to performance. The bigger catch is that MIPS-I doesn't have sdc1/ldc1 either. In this case, we've decided to leave MIPS-I behind, it can continue to use O32 as it currently does.

Hopefully at this point I've convinced you that this first step is ABI compatible and that the 32-bit Debian example I started with will gradually become a distribution that can run in both FR=0 and FR=1 rather than one that requires FR=0. The next step is to allow binaries to require FR=1 mode. At this point, this can actually happen without any further ABI modification since O32+fpxx is also compatible with the O32+fp64 I mentioned in my previous email. This is because O32+fp64 was careful to define the even registers $f20 to $f30 to be callee saved and the odd registers $f21 to $f31 to be caller saved. The main advantage to O32+fp64 is that it is permitted to use the odd FPU registers for storage and arithmetic whereas O32+fpxx is not in case it runs in FR=0 mode where these registers are not usable.

So in summary, each step is ABI compatible with the previous step. The linker will ensure that the end-user doesn't try to do the second step before the first step is finished since it will refuse to link a binary that contains both O32 and O32+fp64. It will produce an O32 binary given a combination of O32+fpxx, and similarly a O32+fp64 binary given a combination O32+fpxx and O32+fp64.

Curious why an extension to o32 for this and not, for example, just using n32?

N32 is an ABI that requires 64-bit general purpose registers so it's not supportable on a 32-bit ISA. More importantly, it would be difficult (if not impossible) to arrange that downstream source bases transition all their code to a new ABI at once. The seamless migration from O32 to O32+fpxx allows source bases to transition piece by piece and therefore allows us to drive the migration using the compiler and the natural tendency for living code to be recompiled at some point. Without this, it's doubtful that downstream sources would make the transition at all as evidenced by previous unsuccessful attempts at updating the ABI. Another important reason is some projects (e.g. Android) need to be able to execute the previously compiled apps from earlier toolchains without modification.

So in summary, each step is ABI compatible with the previous step. The linker will ensure that the end-user doesn't try to do the second step before the first step is finished since it will refuse to link a binary that contains both O32 and O32+fp64. It will produce an O32 binary given a combination of O32+fpxx, and similarly a O32+fp64 binary given a combination O32+fpxx and O32+fp64.

Interesting. I'd seen some of the discussion, but not read it in any detail.

Curious why an extension to o32 for this and not, for example, just using n32?

N32 is an ABI that requires 64-bit general purpose registers so it's not supportable on a 32-bit ISA. More importantly, it would be difficult (if not impossible) to arrange that downstream source bases transition all their code to a new ABI at once. The seamless migration from O32 to O32+fpxx allows source bases to transition piece by piece and therefore allows us to drive the migration using the compiler and the natural tendency for living code to be recompiled at some point. Without this, it's doubtful that downstream sources would make the transition at all as evidenced by previous unsuccessful attempts at updating the ABI. Another important reason is some projects (e.g. Android) need to be able to execute the previously compiled apps from earlier toolchains without modification.

That's fair. I did know the 64-bit register requirement, but had
assumed that with 64-bit floating point that the integer registers
were also 64-bit since other than a couple of processors that's been a
fairly constant thing for MIPS (r5900 as a weird, and notable
exception). If that's not the case, then sure o32 makes sense.

-eric

>> Curious why an extension to o32 for this and not, for example, just using
n32?
>
> N32 is an ABI that requires 64-bit general purpose registers so it's not
supportable on a 32-bit ISA. More importantly, it would be difficult (if not
impossible) to arrange that downstream source bases transition all their code
to a new ABI at once. The seamless migration from O32 to O32+fpxx allows
source bases to transition piece by piece and therefore allows us to drive the
migration using the compiler and the natural tendency for living code to be
recompiled at some point. Without this, it's doubtful that downstream
sources would make the transition at all as evidenced by previous
unsuccessful attempts at updating the ABI. Another important reason is
some projects (e.g. Android) need to be able to execute the previously
compiled apps from earlier toolchains without modification.

That's fair. I did know the 64-bit register requirement, but had assumed that
with 64-bit floating point that the integer registers were also 64-bit since
other than a couple of processors that's been a fairly constant thing for MIPS
(r5900 as a weird, and notable exception). If that's not the case, then sure
o32 makes sense.

MIPS32r6/MIPS64r6 removes support for FR=0 mode so MIPS32r6 is the first 32-bit ISA that requires 64-bit floating point registers and 32-bit integer registers. It's been an option for implementations that support FR=1 mode for a while but people seem to have stuck with FR=0 mode for compatibility or possibly because it's not the default.

>> Curious why an extension to o32 for this and not, for example, just using
n32?
>
> N32 is an ABI that requires 64-bit general purpose registers so it's not
supportable on a 32-bit ISA. More importantly, it would be difficult (if not
impossible) to arrange that downstream source bases transition all their code
to a new ABI at once. The seamless migration from O32 to O32+fpxx allows
source bases to transition piece by piece and therefore allows us to drive the
migration using the compiler and the natural tendency for living code to be
recompiled at some point. Without this, it's doubtful that downstream
sources would make the transition at all as evidenced by previous
unsuccessful attempts at updating the ABI. Another important reason is
some projects (e.g. Android) need to be able to execute the previously
compiled apps from earlier toolchains without modification.

That's fair. I did know the 64-bit register requirement, but had assumed that
with 64-bit floating point that the integer registers were also 64-bit since
other than a couple of processors that's been a fairly constant thing for MIPS
(r5900 as a weird, and notable exception). If that's not the case, then sure
o32 makes sense.

MIPS32r6/MIPS64r6 removes support for FR=0 mode so MIPS32r6 is the first 32-bit ISA that requires 64-bit floating point registers and 32-bit integer registers. It's been an option for implementations that support FR=1 mode for a while but people seem to have stuck with FR=0 mode for compatibility or possibly because it's not the default.

Wow. Interesting. The world moves forward.

Though why not require 64-bit registers? That's horribly off-topic for
the list though and we can chat about that offline :slight_smile:

-eric