similar to: [LLVMdev] Mips target instruction set

Hi William, As Bruno mentioned in his email, support for MIPS64 hasn't been added yet. Do you have any plans how you want to proceed? As you can see in the source code, a lot of things were implemented without 64-bit support in mind although we knew at some point we would need to support it. I am a little worried that you or I might have to make quite a few changes to what is already there

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? -- Best Regards, Yu Rong Tan

Hi LLVM developers, GCC[1] is able to use Loongson ISA[2] for instruction selection: $ cat hello.c #include <stdio.h> int main(int argc, char *argv[]) { printf("Hello World\n"); return 0; } $ gcc -O0 -S hello.c $ cat hello.s .file 1 "hello.c" .section .mdebug.abi64 .previous .nan legacy .gnu_attribute 4, 1 .abicalls

Hi, I noticed that klibc started crashing on 64-bit MIPS and in my quest to fix the bug I got a bit carried away and fixed a few other things as well. Here are various miscellaneous MIPS patches, although the first patch is the important one. Thanks, James *** BLURB HERE *** James Cowgill (5): mips64: compile with -mno-abicalls mips: use -Ttext-segment when linking shared library

- my old email address. The ISA_* classes might not be the best choice for this. There's an overall hierarchy and ordering to the ISA_* classes since they represent the generations of the MIPS ISA. If these extensions are available in Loongson chips based on MIPS32r1 and MIPS32r2 for example, it becomes difficult to describe with ISA_* classes without duplicating instruction definitions or

On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > 0x12 semantics nor does it provide a publicly accessible link to > documentation that does. Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > 3) it really should have explained what you did with >

On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > 0x12 semantics nor does it provide a publicly accessible link to > documentation that does. Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > 3) it really should have explained what you did with >

Hi Matheus, Thank you for your information! Do you known where do download MIPS ABI/EABI document? Thanks in advance! -- Best Regards, Yu Rong Tan On Thu, Jun 12, 2014 at 7:14 PM, Matheus Almeida <Matheus.Almeida at imgtec.com> wrote: > 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

Hi Eric, The main thing we need to fix is that the selection between ELF32/ELF64 needs to depend on the ABI being N64 and not on whether we used a mips-linux-gnu triple versus a mips64-linux-gnu triple. So 'clang -target mips-linux-gnu' -mips64r2 -mabi=64' should produce an ELF64 and 'clang -target mips64-linux-gnu -mips32r2 -mabi=32' should produce an ELF32. In terms of code,

The micro mips processor assembly language is basically 100% the same as mips32/mips64. There are some assembler directives you add but for a base port, but that is all you need to do. However, the binary instruction encoding is entirely different. There are a combination of 16 and 32 bit instruction encodings. The question is, what's the best way to handle this? Extending tablegen ?

Hi, On Wed, Jul 4, 2012 at 9:21 AM, ETANI NORIKO <noriko-e at fc.ritsumei.ac.jp> wrote: > Please advise me how to change a compiler from a host one to a target one. Suppose MIPS toolchain is installed in the $MIPS folder (i.e. mips-linux-gnu-gcc is in the $MIPS/bin folder). Note, if you want to generate little-endian code and/or 64-bit code, you have to create the following links in the

Jeremy, Could you send/attach a small test case that demonstrates the problem? It doesn't need to go past the stage that creates a .o. Also, what version of gnu as are you using? Unless it conflicts with a fundamental llvm/clang philosophy, we are trying to keep Mips assembly compatible with AS. Also, keep in mind that the Mips llvm assembler is current development and is not considered

I'm cross-compiling for MIPS. The test-case is as simple as it can be: void foo() {} $clang -target mips64-octeon-linux -c -B path/to/cross/compiled/mips/assembler a.c And then I look at the object file: $ nm a.o 0000000000000020 t $tmp0 0000000000000000 T foo I would like to know what "$tmp0" is. Furthermore, if I pass -g to clang, I see a whole bunch of such symbols. Some of

We are starting to look at the mips16 and micro mips ports. There are various design issues that people may have some good input on. Especially in how to structure the TD files and other optimizer issues. Mips16 is sort of like thumb and Micro Mips like thumb2 as far as I understand. Mips16 or Micro Mips can live inside of either MIPS32 or MIPS64. In gcc, it's possible using attributes to

On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > smp_read_barrier_depends, smp_store_release and smp_load_acquire match > the asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > This statement doesn't fit MIPS barriers variations. Moreover, there is a reason

Hi, I'd like to experiment with the MIPS and PowerPC backends, but, considering that they aren't widely used processors, I'd like to start with the same environment (OS/ABI/linker) used by the people who work with these backends. So, what OS/ABI/linker use the people who use these backends for production work? Thanks!!

On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > smp_read_barrier_depends, smp_store_release and smp_load_acquire match > the asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > This statement doesn't fit MIPS barriers variations. Moreover, there is a reason

Hi, I would like to ask you how to use Clang in cross-compile environment. My environment is as follows: ------ HOST: 32-bit Fedora 16 with Intel Core i7 gcc/g++ compiler available TARGET: 32-bit mips-typed linux gnu gcc/g++ for 32-bit mips-typed linux available ------ As Clang's option is "-c" in use, my programs are compiled and linked under a host

Hello everyone, in http://reviews.llvm.org/D7696 bhushan added a mips64 UnwindAssembly plugin (a plugin that looks at assembly code to find out how to unwind the stack frame). Since I was about to write such a plugin (though for mips32) myself, I used it as a starting point for a slightly different implementation [1], replacing hard coded instruction encodings by calls to the LLVM disassembler.

On Fri, Jan 20, 2012 at 1:59 PM, reed kotler <rkotler at mips.com> wrote: > We are starting to look at the mips16 and micro mips ports. > > There are various design issues that people may have some good input on. > Especially in how to structure the TD files and other optimizer issues. > > Mips16 is sort of like thumb and Micro Mips like thumb2 as far as I > understand.