Threaded Code

[bloodline]

So here I am thinking about an idea... And it turns out my idea already has a name, "Threaded Code"!

My question is, is there any C/C++ legal way to jump to an address? A computed Goto if you will...

goto *someaddress;

[ElPolloDiabl]

Don't no too much about C, but I read that it explicitly doesn't allow such things.

[bloodline]

Don't no too much about C, but I read that it explicitly doesn't allow such things.

Yeah... I think I've found a gcc extention that allows it... But I'd prefer something more portable

[skurk]

Yes, something like this should work

void (*app)() = (void(*))0x123456;

and then later

app();

I can't test this right now, but I'm pretty sure the above would jump to addres 0x123456.

[Karlos]

So here I am thinking about an idea... And it turns out my idea already has a name, "Threaded Code"!

My question is, is there any C/C++ legal way to jump to an address? A computed Goto if you will...

goto *someaddress;

The most obvious legal way to do this is to use a table of function pointers.

[bloodline]

Yes, something like this should work

void (*app)() = (void(*))0x123456;

and then later

app();

I can't test this right now, but I'm pretty sure the above would jump to addres 0x123456.

No, that's a function pointer which will invoke the calling convention (saving registers etc) which would add a lot of overhead a threaded code Virtual Machine...

[Karlos]

No, that's a function pointer which will invoke the calling convention (saving registers etc) which would add a lot of overhead a threaded code Virtual Machine...

Well the gcc extension is as portable as gcc is. If you keep your dubious computed branch target code to just one translation unit, you could always make it an exception in your makefile and have everything else all nice and ANSI.

[bloodline]

The most obvious legal way to do this is to use a table of function pointers.

I appreciate the advice (and from skurk too), but a function pointer is just too expensive in this regard... My VM needs to run on my 100mhz ARM M3 microcontroller... We have to think lightweight! But I also need it to be portable so I can test it on my test machine... An x86... So ARM Asm is going to be problematic...

[skurk]

No, that's a function pointer which will invoke the calling convention (saving registers etc) which would add a lot of overhead a threaded code Virtual Machine...

Oh, then I misunderstood your question. :-)

[bloodline]

Well the gcc extension is as portable as gcc is. If you keep your dubious computed branch target code to just one translation unit, you could always make it an exception in your makefile and have everything else all nice and ANSI.

Yeah, that's almost certainly the most intelligent way to do it!

[bloodline]

No, that's a function pointer which will invoke the calling convention (saving registers etc) which would add a lot of overhead a threaded code Virtual Machine...

Oh, then I misunderstood your question. :-)

Not really, your advice was good, I didn't provide enough specification for you! As Karlos has also pointed out function pointers are the legal way to do this... I just don't want to save the registers for every function call!

[bloodline]

If I'm happy to stay with gcc, then this seems to be the winner:

http://docs.freebsd.org/info/gcc/gcc.info.Labels_as_Values.html

Bit sucky really...

[commodorejohn]

If you're just writing for ARM and testing on x86, couldn't you use a conditionally-compiled bit of assembler like:

Code: [Select]

#ifdef ARM
asm { /* whatever */}
#else
asm { /* x86 equivalent */}
#endifor somesuch?

[bloodline]

If you're just writing for ARM and testing on x86, couldn't you use a conditionally-compiled bit of assembler like:

Code: [Select]

#ifdef ARM
asm { /* whatever */}
#else
asm { /* x86 equivalent */}
#endifor somesuch?

It's not the code paths that I have a problem with... it's maintaining two code paths :lol: and in ASM too... kinda defeats the point of using C in the first place

[itix]

Not really, your advice was good, I didn't provide enough specification for you! As Karlos has also pointed out function pointers are the legal way to do this... I just don't want to save the registers for every function call!

Necessarily it is not saving the registers for every function call.  It is platform specific...