Thread: Copying WHOLE Functions

The inline assembler is added as a nice bonus. And, as I said, its not encouraged or used in BL's libraries.

Do you know many multimedia applications code for SSE2? and MMX? Take games or codecs. Those tehnologies aren't guaranteed to be on the user's proccessor but they use a if or something to determine which version to run. Same thing with BL, asm, native, normal code.

BTW, It's nice talking to another intellectual programmer and not a newb. Also that from your profile, you're young too (well partly, lol).

Uh no. Not inline. I'm not stupid. I wanted to copy its code, paste it into an array, remove the returns, repeat, and run. Inline code implies that you have some sort of pipeline to determine which intruction to run. That's what I have right now, a pipeline with function pointers. But, that's not what i'm trying to do right now, hence primitive JIT compiler.

I'd like to see you do that at runtime, when you don't know which order you have to place those functions. And, without a for loop when you run it. OK:

functions:
add, mov, sub, mul
0 1 2 3

in comes the bytecode: 0 3 2 1 2

before running (JIT'ing, hehe):
make new char array
while removing the 'ret' s:
insert the ACTUAL CODE of add
insert the ACTUAL CODE of mul
insert the ACTUAL CODE of sub
insert the ACTUAL CODE of mov
insert the ACTUAL CODE of sub
insert one 'ret'
store this char array
make function pointer to that char array

when function is called: call up the function pointer

This saves time, one function is called instead of 5. What you mean by inlining is:

// the functions are inline
for <as many instructions as there are>
{
switch (instructionID)
{
case 0:
add(); break;
case 1:
mov(); break;
case 2:
sub(); break;
case 3:
mul(); break;
}
}

I tested it, this type of pipeline is slower than function pointers stored in an array, as I described how I used in a previous post. But cloning the functions is even faster, if it can be done, and safely if done right. I'm pretty sure you can, but unsure of how.

"inline" is only a hint to the compiler to generate an inline function, not a command. What happens when you take the address of an inline function via a function pointer? Two copies of the function are most likely generated.

If you take an address of an inline function, it acts just like ANY other function. Its ONLY when you explicitly call it when it inlines. BTW, in visual studio, __forceinline forces the inline unless its recursive.

OK, just tested, I was able to clone the function. But it's unsafe, crashes for some reason when I use Debug build and not really stable. I also can't figure out how to remove the return statement so that the next function can execute. How many bytes is it? 1? 4? That would be a major obstacle making it all safe which is sure possible. How could you do it in ASM? If you could provide any assistance in ANY way to the project, please do. This goes out to all of you!

[email protected]
www.blue-lightning.tk

(Everything is being redone, most of the info on the site is old except, well the news, .)

This would be difficult enough to do in 1987 under dos. Expecting to do this under Windows Uberprofits from .NET to feed a P4 is begging for grief. Forget trying to copy and modify the compilers emitted opcodes, those were generated with a large number of assumptions that you are brutally violating. If you really want to do this you are going to have to become intimately familiar with how to generate and align the opcodes you need for your JIT compiled functions yourself. You will then need to either create a new segment, write, properly formatted, the codes you need, then mark that segment as text and do your context switch into the new read-only segment, then return and restore the state to whatever the assumptions .NET expected when you yanked the world out from under it. You can also mark your existing code segment as r/w and tell the linker to give you some room to party on. The latter will slow down your entire program, possibly quite painfully. The former takes quite a bit of time to get the new segment, but afterwards runs just as fast as dynamically loaded functions. You will also probably trip most anti virus software while doing any of this.

Finally have a look at pfe a forth environment that needs to do a lot of the things you are doing.

I can't stress enough that the information on the site is old. It was made when the BL project was first shown to the public, around August.

BL is platform independent, or else there would be no sense in making a VM. And the inline ASM is compiled during the compiling phase. It's stored in binary format inside the bytecode. It's called using a function pointer. It works. But, it's not platform independent. You can ALWAYS test for the target operating system at runtime to determine whether to execute it or not. Or maybe, the VM will test for that.

As for the JIT, it's probably not going to happen, it would be cool though but it's too much work for now. Maybe later unless I can get some help...

Since this board is awesome, I think, I will repost on similar subject once plan #5 is out to check out what you guys think of it. Everything will be updated at that time.