I have written some code in C and need to convert this to MIPS 64, with and without optimisation. I have been trying to convert this with gcc but this converts it to x86 which is far more complex. Furthermore, I have been trying to find a cross compiler but have not been able to get any compiler to work. Any help and suggestions will tremendously be appreciated.
Kind regards,
After downloading and installing Codesourcery codebench for MIPS, invoke the MIPS gcc cross compiler for the MIPS 64 revision 2 architecture as follows:
C:\Program Files (x86)\CodeSourcery\Sourcery_CodeBench_Lite_for_MIPS_GNU_Linux\bin\mips-linux-gnu-gcc -march=mips64r2 foo.c -S
This generates MIPS assembly source code in foo.s.
The documentation that was installed with codebench will tell you the other possible values for the -march option. Other gcc flags like -S and -O work as normal.
If you use a MIPS cross compiler, instead of a gcc that targets x86, you can complete this "conversion" (compilation). If you need to find a MIPS cross compiler (gcc), you can get one pre-built from codesourcery.com
The wording in your question seems to suggest you don't care as much that the output is MIPS, but rather you want the output to be less complex than x86. If this is the case, you might also examine the ARM output.
Related
Recently I was told to look at how C functions are compiled into LLVM bytecode, and then how the LLVM bytecode is translated into x86 ASM. As a regular GNU/gcc user, I have some questions about this. To put it mildly.
Does GNU/gcc compile to bytecode, too? Can it? I was under the impression that gcc compiles directly into ASM. If not, is there a way to view the bytecode intermediary as there is with the clang command?
~$ clang ~/prog_name.c -S -emit-llvm -o - <== will show bytecode for prog_name.c.
Also, I find bytecode to be rather byzantine. By contrast, it makes assembly language seem like light reading. In other words: I have little idea what it is saying.
Does anyone have any advice or references for vaguely deciphering the information that the bytecode gives? Currently I compare and contrast with actual ASM, so to say it is slow going is a compliment.
Perhaps this is all comically naive, but I find it quite challenging to break through the surface of this.
Perhaps try taking a look at the language reference.
As far as I know, GCC does have an IR as well known as GIMPLE (another reference here).
If you mean that you would rather analyze the assembly output instead of the IR, you can take a look at this question which describes how to output an assembly file.
So it is relatively straightforward to tell from the symbols embedded in an executable if an Intel compiler was used to compile it, e.g. from the presence of symbols like __intel_proc_init in the executable.
Is there a way to tell what version of the Intel compiler was used to compile the binary using similar diagnostics?
So I think I figured out a partial answer to my own question. Using the strings utility, I was able to extract the following strings from the Fortran executable:
#(#)Intel Fortran RTL Message Catalog V10.1-101 01-Aug-2007
from another Fortran executable, I found the following strings:
/opt/intel/Compiler/11.1/073/bin/intel64/ifort
#(#)Intel Fortran RTL Message Catalog V11.1-107 16-Mar-2010
however, I was not able to extract any such string from C compiled executables.
PEID is able to do this for MSVC binaries, so you may want to check it out and see if it works for intel, if so then you'd need to find out from the makers what they scan for in the PE/obj dump (iirc some of the info is in plain text in the PE)
The following Fortran source code will output the Intel compiler version at run-time. Obviously similar code in other languages.... Will that meet your need? If not, it might give a clue to a symbol in the executable.
#ifdef __INTEL_COMPILER
write (*, 1050) __INTEL_COMPILER
1050 format ( "Fortran code compiled with Intel ifort, version ", I0 / )
#endif
Is there anywhere I can find side-by-side examples of dead simple C and x86 programs? The examples I've found so far on the Internet seem to jump straight from "here's Hello World in x86" to "write your own operating system!" I'm having trouble internalizing what has to happen when you do things like call a function.
I would recommend a look at GCC's intermediate assembly output, for example call
gcc -S a.c
then look at a.s
Most of the time, smaller and easier to understand assembly is generated by optimizing, so you would rather use
gcc -O -S a.c
If you mean x86 assembly language, use objdump --disassemble myprog (on any GNU system) to show the assembly language generated by your C program. If your system doesn't have objdump, you can use ndisasm.
Assuming you mean x86 assembler then with gcc you can use gcc -S yourhelloworldprogram.c to get assembler output. For Visual Studio you can get assembler output by following this: How do I get the assembler output from a C file in VS2005
I reccommend ddd. You can have the both C sources (if you built with debug symbols) and the machine code showing. You can also step over the code interactively probing register and memory values. A great learning tool.
On gcc you can use the -save-temps -fverbose-asm options which is better than the -S option because it still generates the object file and you get also the preprocessor file. The verbose-asm is also important because it adds comments to the assembly output that make the link between the function and variable names of your program and the generated assembly code. Especially when generating with optimization it often is difficult to make the link between the source C and the assembly.
I am compiling on a 64 bit architecture with the intel C compiler. The same code built fine on a different 64 bit intel architecture.
Now when I try to build the binaries, I get a message "Skipping incompatible ../../libtime.a" or some such thing, that is indicating the libtime.a that I archived (from some object files I compiled) is not compatible. I googled and it seemed like this was usually the result of a 32->64 bit changeover or something like that, but the intel C compiler doesnt seem to support a -64 or some other memory option at compile time. How do I troubleshoot and fix this error?
You cannot mix 64-bit and 32-bit compiled code. Config instructions for Linux are here.
You need to determine the target processor of both the library and the new code you are building. This can be done in a few ways but the easiest is:
$ objdump -f ../../libtime.a otherfile.o
For libtime this will probably print out bunches of things, but they should all have the same target processor. Make sure that otherfile.o (which you should substitute one of your object files for) also has the same architecture.
gcc has the -m32 and -m64 flags for switching from the default target to a similar processor with the different register and memory width (commonly x86 and x86_64), which the Intel C compiler may also have.
If this has not been helpful then you should include the commands (with all flags) used to compile everything and also information about the systems that each command was being run on.
Is there an easy way (like a free program) that can covert c/c++ code to x86 assembly?
I know that any c compiler does something very similar and that I can just compile the c code and then disassemble the complied executable, but that's kind of an overkill, all I want is to convert a few lines of code.
Does anyone know of some program that can do that?
EDIT: I know that GCC compiler does that but it's AT&T syntax and I'm looking for the Intel syntax (not sure if it's called intel syntax or not). The AT&T syntax looks a bit like gibberish to me and some commands use operands in reverse order and not how I'm used to and it can get really confusing.
GCC can output Intel syntax assembly using the following command line:
gcc -S input.c -o output.asm -masm=intel
Gcc can do it with the -S switch, but it will be disgustingly ugly at&t syntax.
gcc will generate assembly if you pass it the -S option on the command line.
Microsoft Visual C++ will do the same with the /FAs option.
The lcc compiler is a multiplatform cross-compiler. You can get it to produce Intel syntax assembly code by
lcc -S -Wf-target=x86/win32 foo.c
I find assembly code from lcc significantly easier to read than what gcc spits out nowawadays.
Your compiler is already doing that as you've stated, and most likely will have an option to stop before assembling.
For GCC, add the -S flag.
gcc -S x.c
cat x.s
Edit: If your program is pretty short, you could use the online service at https://gcc.godbolt.org/.
if you are using gcc as a compiler, you can compile with the -S option to produce assembly code. see http://www.delorie.com/djgpp/v2faq/faq8_20.html
As many people point out most compilers will do that. If you don't like the syntax,a bit of work with awk or sed should be able to translate. Or I'd be surprised if there wasn't a program that did that bit for you already written somewhere.
In VC++ the following command can be used to list the assembly code.
cl /FAs a.c
notice
every architecture has its own unique names and even build differently
now when you know the stacks involved using asm volatile
would b the perfect solution