- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi everyone!
I'm trying to get computed gotos to work with the Intel C++ Compiler (11.1.065) on Windows using Visual Studio 2008 as my IDE of choice. I hear that ICC like GCC supports this feature, but I can't get it to work. Here's what I'm trying to do:
[cpp]label1: printf("A"); label2: printf("B"); void* x = &&label2; goto *x;[/cpp]This gives me two errors in lines 6 and 7 (error: expected an expression and error: expected an identifier).
I looked all over the web but information on ICC's computed goto support is pretty scarce.
So my question is: what am I doing wrong? Am I missing a compiler option and if so, which one?
Thanks a lot in advance!
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Function pointers would be possible except there will be a performance issue.
First, the context during the dispatch will not be that of the main interpreter loop. This may not be a big issue if the main interpreter context data is static (global). Presumably it is stacked (to permit nested interprited function/subroutines). While you could use a this pointer (make functor a member function) you have the issue of eating up an extra register.
Second, the call and the return will require real memory access for push and pop of return address.
The computed goto eliminates the push and pop and maintains the context of the main interpreter loop.
Third, excepting for specialty functions (maybe pure can do this) the functions generally will have a stack frame (EBP, RBP) and this has associated costs with setup and takedown.
The computed goto will be much superior in that respect.
Harry,
Intel ICC permits the GNU C/C++ style of assembler statements. The GNU style assembler statements can be written in a more portable manner (has abstract syntax)than using the MS MASM format which is platform specific. I think it will be worth your while to do a little investigation on this issue.
Jim Dempsey
First, the context during the dispatch will not be that of the main interpreter loop. This may not be a big issue if the main interpreter context data is static (global). Presumably it is stacked (to permit nested interprited function/subroutines). While you could use a this pointer (make functor a member function) you have the issue of eating up an extra register.
Second, the call and the return will require real memory access for push and pop of return address.
The computed goto eliminates the push and pop and maintains the context of the main interpreter loop.
Third, excepting for specialty functions (maybe pure can do this) the functions generally will have a stack frame (EBP, RBP) and this has associated costs with setup and takedown.
The computed goto will be much superior in that respect.
Harry,
Intel ICC permits the GNU C/C++ style of assembler statements. The GNU style assembler statements can be written in a more portable manner (has abstract syntax)than using the MS MASM format which is platform specific. I think it will be worth your while to do a little investigation on this issue.
Jim Dempsey
Link Copied
8 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Seems to be that this feature is only in Linux compilers, and is a GNU Clanguage feature. Microsoft compilers do not implement it.
Our goal is to be fully source & binary-compatible with gcc for Linux compilers, while fully compatible with Microsoft compilers in Windows.
So it looks to bea tough call to get it in Windows. Nevertheless, what benefits does it offer to your code when it could be done with the lack of it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the reply!
I'm writing a bytecode interpreter and the Linux version of it (which I compile with GCC) has greatly benefited from replacing the switch-based dispatch with computed gotos. I was looking for a way to do the same on Windows and thought ICC might be it. I guess Windows users will have to live with the non-threaded VM then...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Why not use inline assembler code?
Jim
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yeah, thought about that as well. I'm worried about the combinatory explosion though, as the interpreter is highly portable. I already have ifdefs to distinguish between the switch-case and computed-goto code paths in there, don't know if I want to further complicate matters with inline assembly (x86, x86_64, ARM, ...). I'll have to think about that.
Thanks anyway!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dare I suggest function pointers? I.e. make each case a separate function and call it through a pointer?
Dale
Dale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Function pointers would be possible except there will be a performance issue.
First, the context during the dispatch will not be that of the main interpreter loop. This may not be a big issue if the main interpreter context data is static (global). Presumably it is stacked (to permit nested interprited function/subroutines). While you could use a this pointer (make functor a member function) you have the issue of eating up an extra register.
Second, the call and the return will require real memory access for push and pop of return address.
The computed goto eliminates the push and pop and maintains the context of the main interpreter loop.
Third, excepting for specialty functions (maybe pure can do this) the functions generally will have a stack frame (EBP, RBP) and this has associated costs with setup and takedown.
The computed goto will be much superior in that respect.
Harry,
Intel ICC permits the GNU C/C++ style of assembler statements. The GNU style assembler statements can be written in a more portable manner (has abstract syntax)than using the MS MASM format which is platform specific. I think it will be worth your while to do a little investigation on this issue.
Jim Dempsey
First, the context during the dispatch will not be that of the main interpreter loop. This may not be a big issue if the main interpreter context data is static (global). Presumably it is stacked (to permit nested interprited function/subroutines). While you could use a this pointer (make functor a member function) you have the issue of eating up an extra register.
Second, the call and the return will require real memory access for push and pop of return address.
The computed goto eliminates the push and pop and maintains the context of the main interpreter loop.
Third, excepting for specialty functions (maybe pure can do this) the functions generally will have a stack frame (EBP, RBP) and this has associated costs with setup and takedown.
The computed goto will be much superior in that respect.
Harry,
Intel ICC permits the GNU C/C++ style of assembler statements. The GNU style assembler statements can be written in a more portable manner (has abstract syntax)than using the MS MASM format which is platform specific. I think it will be worth your while to do a little investigation on this issue.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Harry,
As Jim said, on Windows the Intel C++ Compiler does support GNU style asm statement. I remember there are a few limitations. But it should work in most cases.
Jennifer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi everyone,
thanks for the great advice. I will try the GNU-style asm statements then.
Thanks and cheers,
Harry
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page