Compiler's use of function parameters as temporaries

[John Miles]

Hi --

This is a bit of an implementation-specific problem, but I'd like to
post it here to see if there's a general answer within the auspices of
the language.

I'm developing a high(er)-level scripting language designed explicitly
to complement C++. One of the language's features is the ability to
pass "out" parameters to an MSVC __cdecl function by reference. After
the C++ function returns, but before popping the parameters from the
stack, the scripting-language VM copies any out-parameters back from the
C++ stack frame to the variables they originally came from. In this way
any modifications made by the C++ function to its parameters are
propagated back to the scripting language.

As you might guess, this approach has problems when compiling with
optimization turned on. In theory the C++ compiler may decide that any
write operations to parameters which are never subsequently read can be
omitted. In practice, I haven't seen that happening, but what I *have*
seen is that the compiler likes to reuse function parameters when it
needs to allocate a temporary. Hilarity ensues when the VM retrieves an
unrelated temporary from the stack instead of the parameter it expects.

Is there a general, implementation-independent way to tell the compiler
(a) not to reuse a function parameter as a temporary; and (b) not to
perform dead-code elimination on writes to function parameters?

I experimentally tried applying "volatile" to a parameter ("volatile
Mat4x4 *SRC"), and while MSVC accepted the code, SRC still got reused as
a temporary within the body of the function.

Similarly, passing the parameters by reference rather than as pointers
("Mat4X4 &SRC") doesn't make any difference.

Thanks in advance for any suggestions.

-- jm

 

[tom_usenet]

Hi --

This is a bit of an implementation-specific problem, but I'd like to
post it here to see if there's a general answer within the auspices of
the language.

I'm developing a high(er)-level scripting language designed explicitly
to complement C++. One of the language's features is the ability to
pass "out" parameters to an MSVC __cdecl function by reference.

How are the parameters in the C++ function declared? If parameters are
passed by value, then the compiler is highly likely to modify them
arbitrarily inside the function. In addition, the function might even
operate on a copy of the parameter, so that changes aren't accessible
in the calling stack frame.

After

the C++ function returns, but before popping the parameters from the
stack, the scripting-language VM copies any out-parameters back from the
C++ stack frame to the variables they originally came from. In this way
any modifications made by the C++ function to its parameters are
propagated back to the scripting language.

As you might guess, this approach has problems when compiling with
optimization turned on. In theory the C++ compiler may decide that any
write operations to parameters which are never subsequently read can be
omitted. In practice, I haven't seen that happening, but what I *have*
seen is that the compiler likes to reuse function parameters when it
needs to allocate a temporary. Hilarity ensues when the VM retrieves an
unrelated temporary from the stack instead of the parameter it expects.

Is there a general, implementation-independent way to tell the compiler
(a) not to reuse a function parameter as a temporary; and (b) not to
perform dead-code elimination on writes to function parameters?

If the parameter is passed by value there is no reason for the
compiler to leave the variable in the state in which it was passed,
and I doubt there is a way to make it.

I experimentally tried applying "volatile" to a parameter ("volatile
Mat4x4 *SRC"), and while MSVC accepted the code, SRC still got reused as
a temporary within the body of the function.

Similarly, passing the parameters by reference rather than as pointers
("Mat4X4 &SRC") doesn't make any difference.

It sounds like you are doing the wrong thing. You need to have the C++
function take pointers, not values. References might work, bearing in
mind that references are probably implemented as pointers.

Tom