Is it possible to convert C/C++ source code to assembly?

Question

Is it possible to somehow convert a simple C or C++ code (by simple I mean: taking some int as input, printing some simple shapes dependent on that int as output) to assembly language? If there isn't I'll just do it manually but since I'm gonna be doing it for processors like Intel 8080, it just seemed a bit tedious. Can you somehow automate the process?

Also, if there is a way, how good (as in: elegant) would the output assembly file source code be when compared to just translating it manually?

Solution 1

Most compilers will let you produce assembly output. For a couple of obvious examples, Clang and gcc/g++ use the -S flag, and MS VC++ uses the -Fa flag to do so.

A few compilers don't support this directly (e.g., if memory serves Watcom didn't). The ones I've seen like this had you produce an object file, and then included a disassembler that would produce an assembly language file from the object file. I don't remember for sure, but it wouldn't surprise me if this is what you'd need to do with the Digital Mars compiler.

To somebody who's accustomed to writing assembly language, the output from most compilers typically tends to look at least somewhat inelegant, especially on a CPU like an x86 that has quite a few registers that are now really general purpose, but have historically had more specific meanings. For example, if some piece of code needs both a pointer and a counter, a person would probably put the pointer in ESI or EDI, and the counter in ECX. The compiler might easily reverse those. That'll work fine, but an experienced assembly language programmer will undoubtedly find it more readable using ESI for the pointer and ECX for the counter.

Solution 2

Take look at gcc -S:

gcc -S hello.c # outputs hello.s file

Other compilers that maintain at lest partial gcc compatibility may also accept this flag. LLVM's clang, for example, does.

Solution 3

Well, yes there is such a program. It's called "Compiler"

To answer your edit: The elegance of the output depends on the optimization of your compiler. Usually compilers do not generate code we humans would call "elegant".

Solution 4

Most folks here are right, but seem to have missed the note about 8080 (no wonder, it's not in the title :). However, Google comes to the rescue as always - looking for compiler for 8080 produces some nice results like these:

• http://www.bdsoft.com/resources/bdsc.html
• http://tack.sourceforge.net/

Most of these are pretty old and might be poorly maintained. You might also try 8085 which is fairly similar

View more solutions

Comments

[jrd1]

Note that with gcc, the assembly output is in AT&T style, though.

[Skeen]

There's a switch for Intel syntax, I think.

[el.pescado - нет войне]

-masm switch chooses asm flavor, it seems, I havent used it however.

[Straightfw]

Thanks a lot. I have a question regarding the registers you mentioned: as I said, I'm going to need an assembly code such that it works under Intel 8080 or similar "ancient" processors. Is there any way to simulate (or somehow "tell") the compiler what kind of CPU it's compiling for so that I end up with an assembly code that doesn't use registers which simply aren't present in 8080 or 8086?

[Seva Alekseyev]

Elegant in terms of runtime efficiency it will be, but easily readable by humans it won't be :)

[Admin]

Also, I'm not sure that GCC will generate code that will run on an 8080 anymore!

[el.pescado - нет войне]

You may be right... You could target particular CPU eith -march flag, but oldest you can acieve is probably i386.

[Jerry Coffin]

@Straightfw: From a practical viewpoint, about all you can (probably) do is find an older compiler that targets (for example) an 8086. Most compilers are divided into a front-end devoted to the source language and a back-end devoted to the target processor, so (in theory) you could write a back-end targeting the processor in question, but it's generally non-trivial. For a really limited processor could be quite difficult indeed.

[MSalters]

@Straightfw: It's more than just a few registers missing. Most practically, all 32 and 64 bits registers are missing pre-80386. And long is still a 32 bits type. That means that your compiler must be able to do something which no modern compiler cares for, synthesizing 32 bits operations using only 16 bits registers.

[MSalters]

@el.pescado: m68K dates back to 1979, only one year older than the 8086 itself. It's a much saner arch than x86, so it was widely used in embedded systems.

[el.pescado - нет войне]

It's true, I meant "the oldest among x86"

[Straightfw]

Thanks a lot for addressing the little but oh so important detail of my question :)