Convert Inline Assembly Code to C++

How to convert inline assembly in msbuild to gcc

Inline assembler is standardized in C++, so try to follow the C++ standard (see this) instead of using non-standard extensions. That is, use this syntax:

asm ( string_literal ) ;

GCC-Inline-Assembly-HOWTO for details and alternative (non-standard) ways.

Is there a way to insert assembly code into C?

Using GCC

__asm__("movl %edx, %eax\n\t"
"addl $2, %eax\n\t");

Using VC++

__asm {
mov eax, edx
add eax, 2
}

How to inline assembly code using bits (hard code) in C?

You can put raw bytes in with .byte:

__asm__ (".byte 0xf0, 0x0b, 0xaa");

Converting VS to GCC inline assembly

You can learn more about GCC assembler templates in the GCC documentation. Peter Cordes has a Stackoverflow answer with a list of inline assembler if you wish to learn more. MSVC and GCC differ greatly. GCC has no knowledge of what a template does or the instructions executes. GCC instead does substitutions based upon a list of constraints - input, output, and clobber.

A GCC extended assembler template that would be a close approximation to the MSVC inline assembler could look like:

__asm__ (
"mov %%fs:0x18, %0\n\t"
"mov 0x30(%0), %0\n\t"
"mov 0x0C(%0), %0\n\t"
: "=r"(pmInfo));

In your case you need a single register to use for the internal usage. It doesn't need to be EAX but can be any register GCC has available. We use an output constraint of "=r" that says we want GCC to choose an available register. We reference the first (and in this case the only one) constraint via %0 in the assembler template. "=r"(pmInfo) on the constraint says that when the instructions in the template are complete the value in the register chosen will be placed into pmInfo .

GCC extended assembler is a tricky thing to work with, and very easy to get wrong. You might be better off creating an assembler file with a function that returns a pointer to a ProcessModuleInfo structure. This eliminates the need to understand GCC's extended assembler templates, and deal with its intricacies.

Stackoverflow user DavidWohlferd wrote a GCC wiki article giving reasons why using GCC inline assembler should be avoided if possible.


If the %0 looks a bit confusing, each of the input and output operands can be given a symbolic name that can be used as an alternative instead of % and a number in the template. The code could have looked like this:

__asm__ (
"mov %%fs:0x18, %[tempreg]\n\t"
"mov 0x30(%[tempreg]), %[tempreg]\n\t"
"mov 0x0C(%[tempreg]), %[tempreg]\n\t"
: [tempreg]"=r"(pmInfo));

The [tempreg] in square brackets gives the operand a name as alternative to using an ordinal position. This makes it a bit easier to read the template as well.

Converting Visual C/C++ inline assembly code to GCC equivalent code

You can get rid of the inline ASM, use

void* StackPtr = &StackPtr;

Convert ASM to C (not reverse engineer)

You can absolutely make a c program from assembler. The problem is it may not look like what you are thinking, or maybe it will. My PIC is rusty but using another assembler, say you had

add r1,r2

In C lets say that becomes

r1 = r1 + r2;

Possibly more readable. You lose any sense of variable names perhaps as values are jumping from memory to registers and back and the registers are being reused. If you are talking about the older pics that had what two registers an accumulator and another, well it actually might be easier because variables were in memory for the most part, you look at the address, something like

q = mem[0x12];
e = q;
q = mem[0x13];
e = e + q;
mem[0x12] = e;

Long and drawn out but it is clear that mem[0x12] = mem[0x12] + mem[0x13];

These memory locations are likely variables that will not jump around like compiled C code for a processor with a bunch of registers. The pic might make it easier to figure out the variables and then do a search and replace to name them across the file.

What you are looking for is called a static binary translation, not necessarily a translation from one binary to another (one processor to another) but in this case a translation from pic binary to C. Ideally you would want to take the assembler given in the app note and assemble it to a binary using the microchip tools, then do the translation. You can do dynamic binary translation as well but you are even less likely to find one of those and it doesnt normally result in C but one binary to another. Ever wonder how those $15 joysticks at wal-mart with pac-man and galaga work? The rom from the arcade was converted using static binary translation, optimized and cleaned up and the C or whatever intermediate language compiled for the new target processor in the handheld box. I imagine not all of them were done this way but am pretty sure some were.

The million dollar question, can you find a static binary translator for a pic? Who knows, you probably have to write one yourself. And guess what that means, you write a disassembler, and instead of disassembling to an instruction in the native assembler syntax like add r0,r1 you have your disassembler print out r0=r0+r1; By the time you finish this disassembler though you will know the pic assembly language so well that you wont need the asm to C translator. You have a chicken and egg problem.



Related Topics



Leave a reply



Submit