Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.

How to transform c code to MIPS assembly language code...?

please help me...
I have to use SPIM on PC to run MIPS program.
But I don't know MIPS assembly language.
I need some softwares or tools to transform c language code.
My O.S. is windows2000.Please help me how to do.
Thank a lot.


  • big_endianbig_endian Posts: 20Member
    Ok Trueno, I need to know more about your C / C++ compiler and a couple
    other parameters before I can point you in the correct direction.

    The free SPIM Assembly Language Simulator runs on the PCs but is created
    to run the R2000 and R3000 assembly code. Now something you should
    made aware of, some compilers will compile the source code into
    binaries called (.OBJ) files with a couple of macros included with the
    binary code to help the next step along called Linking, which depending
    on how you have your build options set up, it can create .DLLs, .LIBs,
    .EXEs, .COMs, etc. (if it is a PC based compiler) or for the MIPS based
    compiler it can be output in many forms, .RAW, etc.

    What I need to know is the following:

    What is the name and version of your compiler?

    Is the compiler called a CROSS-PLATFORM Compiler?

    Does it support the MIPS R2K or R3K processors?

    Does it support the MIPS R2K/R3K processors floating point instructions?

    Does it support conversion of macros into pure assembly code?

    Does your compiler support pure or raw binary output?

    The reasons why I ask these question is the following scenarios:

    The version and name of compiler allows me to determine if
    you can convert the C / C++ source into direct assembly when
    it compiles it or if I have to make a module to extract the
    raw data from the .OBJ file. As I had mentioned before, .BIN
    files are the raw assembly / binary files that are suitable
    for SPIM but most .OBJ file formats (and the code / comments / IDs)
    are not. Some Compilers have a direct option to write a
    file that is raw binary in their command line arguments or
    build options (in a windowed GUI version).

    You might as why does it have to be a Cross Platform Compiler.
    Many people say that all C compilers and linkers are cross platform
    types but that's simply not true. The SOURCE and most of the HEADERS
    files are but it doesn't mean that when you go to compile it on one
    machine (regardless if you link it or not) then it can and will become
    incompatible with another using another type of microcode. The
    reason why I say have a compiler that is cross platform is that
    it can compile in the assembly language to your TARGET CPU or DSP
    regardless of what CPU you are using currently.

    Now that we have gone through the major problems when compiling
    a file in a TARGET's machine language or assembly language in
    your case we can move to this next subject. Does your cross platform
    C/C++ compiler recognize the Pragma, Directives, and Definitions
    of the MIPS R2000 and R3000 processors? That is the kicker, if
    your compiler doesn't recognize that stuff or cannot convert the
    C/C++ source code into binaries that the MIPS R2000 / R3000 can
    read and execute, then you're compiler is worthless for what you
    are attempting to do unless you write you're own cross compiler
    that will recognize it but you have a long way to go.

    Something I must relay to you about SPIM. SPIM does not recognize
    the R2000 / R3000 floating point instructions (it's can't use them,
    can't read them, etc., in other words it is unimplemented). That
    means if you got this far and you can get your assembly languages
    to load but are buggy / erroneous. What you need to do is specify
    that the compiler not use Floating Point instructions while compiling
    it to your TARGET file format in R2000 / R3000 assembly code.

    Now about the macros, some compilers will leave macros in an .OBJ file,
    that kind of file is meant to be linked and create an executable of
    some sort. Some compilers also treat their .RAW or .BIN files the same
    way regardless if you have a .DEF (Definitions file) on how to format
    a certain file and what to omit (if anything). This is an unfortunate
    bug on some compilers, that is why I mentioned it. SPIM cannot
    understand assembler macros, other than it's own version of it.

    Another thing, I did not touch base on really also has something to do
    with the compiler or processor mode. There are various flags,
    registers, vectors, and all kinds of crap that is related to the
    processors you are attempting to dump .asm files to. One of the biggest
    pet peaves for people is the Endianess Mode. This mode specifies how
    bytes are loaded in memory and how bits are read in memory according to
    their bit weighting. The most common Endian Mode used in most computers
    is Little Endian Mode. This is where the least signifigant bit has the
    smallest value and the most signifigant bit has the largest number
    representation. Now to really bake your noodle, big endian is just the
    opposite of Little Endian. Now to make things worse (sorry about this),
    MIPS processors can operate in either mode. You need to specify
    this mode for compiling it into an .ASM file. For example, you
    have SPIM running in Little mode and you compile an .ASM file in Big
    mode, either your will get screwy results when you load the file then
    crash the simulator or it won't run at all.

    Endianess, you may ask why there is such a thing. Well years ago,
    computer scientists and engineers found it was easier for the digital
    electronics and CPUs to run more efficiently in big endian mode,
    meaning there is a slight improvement in performance per clock cycle,
    they were able to cut down the amount of time instructions for all
    operations, especially integer and floating point operations.

    I know you are attending a college but what is the ultimate goal
    you are attempting to obtain? Are you learning to become a game
    programmer for the next generation gaming consoles? Like the
    Sony's PS2 / PS3 and the Nintendo's GameCube or Project Silent?

    I have a C/C++ compiler that you can get that is compatible with
    Windows and Linux to make R3000 and MIPS R5900 Emotion Engine coding.
    Those tools are free as well, it would almost be better if you
    used these tools because you could use it as a general compiler
    for the R3000 CPU, since that is what is in the Sony PlayStation 1.

    Let me know more about your situation and what you make of what I
    have just posted to you. I am sorry if this is a little confusing but
    there is so much to compilers and SPIM that is hard to relay in
    just a small amount of text space such as this.


    : please help me...
    : I have to use SPIM on PC to run MIPS program.
    : But I don't know MIPS assembly language.
    : I need some softwares or tools to transform c language code.
    : My O.S. is windows2000.Please help me how to do.
    : Thank a lot.

Sign In or Register to comment.