Just-in-time compiling of assembly for use in a c++ program

[Jan Althaus]

Mostly for testing reasons I'd like to see if it makes sense to chose
the following approach for just-in-time compilation of shaders for a
renderer:
Seeing as the shaders themsefs consist mostly of very basic operations
I'd like to translate them into assembly, have an assembler compile the
binary code and then call the resulting machine code from c++.

The thing is that up until now I have only used inline assembly in my
c++ projects, so there's a few things I hardly know anything about and
would be very greatful if anyone here could point me in the right
direction:
- Having a set of asm instructions, say "addl 5, %%eax" or "add eax, 5"
respectively, how would I go about translating just this one line into
binary? (in a way that doesn't mean i'll have to re-write the whole
thing when porting to a different os if at all possible
- How do I jump into the binary from my c++ app in a way that I can jmp
back at the end of my assembly code segment?

Thanks!

 

[Jack Klein]

Mostly for testing reasons I'd like to see if it makes sense to chose
the following approach for just-in-time compilation of shaders for a
renderer:
Seeing as the shaders themsefs consist mostly of very basic operations
I'd like to translate them into assembly, have an assembler compile the
binary code and then call the resulting machine code from c++.

Your question is really off-topic for this group. While C++ does
define a syntax for embedding inline assembly language in a C++
program, all details about the assembly language and what it does is
completely implementation-defined and outside the scope of C++ itself.

The thing is that up until now I have only used inline assembly in my
c++ projects, so there's a few things I hardly know anything about and
would be very greatful if anyone here could point me in the right
direction:
- Having a set of asm instructions, say "addl 5, %%eax" or "add eax, 5"
respectively, how would I go about translating just this one line into
binary? (in a way that doesn't mean i'll have to re-write the whole
thing when porting to a different os if at all possible

No matter what you do, it will never be portable to a platform using a
different CPU architecture, such as ARM, SPARC, or PowerPC.

As to how you generate binary code from assembly language source code,
you can use system() or a platform specific extension to invoke an
assembler, or you could incorporate some for of assembler in your
program yourself.

- How do I jump into the binary from my c++ app in a way that I can jmp
back at the end of my assembly code segment?

Here's the point where you leave the C++ language standard completely
behind. If, for example, you incorporate some sort of mini assembler
into your program, you could read assembly language source code and
translate it into object code, most likely storing it in an array of
unsigned chars.

If you have a pointer to this array, you still have the problem that
there is no defined conversion between data and code in C++, and in
fact some operating systems do not ever allow a program to try to
execute anything that it can access as data, or write to any memory
that it can execute from.

So you really need to ask this in a group specific to your platform
(Mac?) to find out if this can be done on your platform, and how to do
it. The C++ language just doesn't define this at all.

 

[Robert Mabee]

Seeing as the shaders themsefs consist mostly of very basic operations
I'd like to translate them into assembly, have an assembler compile the
binary code and then call the resulting machine code from c++.

You could literally do that, invoking your standard assembler (ie
with system()) and loading the resulting object code, with library
help if available, if speed isn't an issue.

Perhaps you can structure your shaders as concatenations of short
fragments that you can write and assemble and link to your program,
using a table of pointer and size for each fragment, and then just
write the code to copy the appropriate fragments into a buffer.
The first and last fragments will be function entry and exit.
You will need to overcome whatever hurdle your CPU poses to execution
of what was recently data -- perhaps a system call to execute a
cache flush, or some operation on the pointer to the buffer to label
it as a pointer to code.