SGI: Development

Hi,

Do any of the SGI developpers around have any idea if MipsPro C supports the label value operator ?
Of course it throws errors when hitting the && operator, but maybe there is some hidden -LANG switch that activate this extension ?

Thank you

IBM XLC 8.0 wrote: The label value operator && returns the address of its operand, which must be a label defined in the current function or a containing function. The value is a constant of type void* and should be used only in a computed goto statement. The language feature is an extension to C and C++, implemented to facilitate porting programs developed with GNU C.

What plonker came up with this dim-witted idea?

Wow, I'd like to see some code that makes use of this (and then smack the person who wrote it).

And to answer the question, MIPSpro doesn't support much beyond what the language standards specify. Even gray areas aren't likely to be supported. For example, a problem I've run into: MIPSpro doesn't support variadic macros in C++, though they are included in ANSI C90 and MIPSpro supports them there.

porter wrote: What plonker came up with this dim-witted idea?

pip wrote: Wow, I'd like to see some code that makes use of this (and then smack the person who wrote it).

I found this code in the dispatcher of a direct threaded bytecode interpreter and, frankly, I cannot imagine any other practical use of this
Oh well, I guess I'll either have to rewrite this part of the code, or make use of gcc (which have other drawbacks in my case)...

porter wrote: What plonker came up with this dim-witted idea?

pip wrote: Wow, I'd like to see some code that makes use of this (and then smack the person who wrote it).

Its typically used to get the value of the PC at the point (or after it) at which the statement containing it executes. In kernels, this is sometimes necessary in relation to threads, and it is perhaps also useful in implementing debuggers (and as stated above, emulators/execution engines). AFAIK there is no way to do this in normal C/C++, so you either use a GNU extension, resort to inline assembly (if available), or use a compiler intrinsic (if available).

bplaa.yai wrote:

porter wrote: What plonker came up with this dim-witted idea?

pip wrote: Wow, I'd like to see some code that makes use of this (and then smack the person who wrote it).

I found this code in the dispatcher of a direct threaded bytecode interpreter and, frankly, I cannot imagine any other practical use of this
Oh well, I guess I'll either have to rewrite this part of the code, or make use of gcc (which have other drawbacks in my case)...

Correct, there is no other way to do this (threaded interpreter) short of assembly.
E

kramlq wrote: In kernels, this is sometimes necessary in relation to threads

Actually, setjmp/longjmp do this!

Fine to have things for kernels but not supposedly portable user-land code.

porter wrote:

kramlq wrote: In kernels, this is sometimes necessary in relation to threads

Actually, setjmp/longjmp do this!

Fine to have things for kernels but not supposedly portable user-land code.

Setjmp/longjmp are similar in principle, but may not always be flexible enough. They store context in an opaque jmp_buf structure, and thus may not give access to the low level values you want. Also, they may not give enough control over what is saved/restored (for example, a longjmp blindly reinstating the saved stack pointer can cause problems and undefined behaviour if it is called from outside of the function the corresponding setjump was used in). And this type of requirement can occur outside of the kernel as well - in user level thread libraries for instance. It all depends on the specifics of what you are trying to do really, but setjmp/longjmp are not always suitable.