I'm doing some tests with AngelScript and MSVC8, and I'm also running into problems with the unit tests in release mode.

More specifically the tests TestExecute32MixedArgs and TestExecuteThis32MixedArgs. In both of these cases the tests report that arguments 14,15,16 are wrong.

However, after some tests I have been able to confirm that this is not a problem with AngelScript, but more with the MSVC optimizer.

Debugging the code I can see that the arguments are indeed correct. The problem occurs when the arguments are loaded into the floating point register. Although the disassembly window shows me that the code was correctly generated by MSVC compiler the value loaded from the stack into the floating point register is incorrect. The following instruction is executed:

fld         dword ptr [esp+48h]

Where esp+48h points to the 14th parameter on the stack. The value on the stack at this location is 14.0f. But what is loaded into the st0 register is actually 1#IND. This is what I cannot understand.

It actually seems to fail due to what is already loaded into the other floating point registers, because if I move the unit test to the beginning of the main() function it doesn't fail. The code is exactly the same, only the contents of the floating point registers are different.

The same test work if I compile it without optimization for speed, using the exact same AngelScript library as before.

I'll try to figure out what is going on. But at least I know the problem is not with AngelScript.

[Edited by - WitchLord on February 3, 2006 9:18:15 PM]

I found the problem. [grin] And I'm very pleased to say that it was neither a problem with the AngelScript library, nor with MSVC8's compiler.

The problem wasn't even related to the TestExecute32MixedArgs test case, even though it was in that test the problem was detected. No, the problem was actually in the Test_Object3 test case.

What was happening is that an assignment operator was registered with AngelScript the following way:

float __cdecl AssignFloat2Float(float a,cFloat &b){	b=a;	return b;}

pSE->RegisterObjectType("Float", sizeof(cFloat), asOBJ_CLASS);if(pSE->RegisterObjectBehaviour("Float",asBEHAVE_ASSIGNMENT,"Float& f(float )",asFUNCTION(AssignFloat2Float),asCALL_CDECL_OBJLAST))		return false;

Can you spot the error? cFloat is a class with a single float member.

The problem is that when registering the assignment behaviour AngelScript is told that it is returning a reference to a cFloat class, but in reality it is returning a float by value.

While this didn't cause a problem in this test case, each assignment that the script made, left a float value in the float registers that were never removed again. In TestExecute32MixedArgs the MSVC8 compiler optimized the code so that all eight float registers are filled with values. The problem was that a couple of the registers were already occupied. The CPU (a P3 Celeron, in my case) was actually telling me this right from the start by setting the values to 1#IND instead of the real values, I just didn't understand that.

I'll finally be able to leave this problem and move on to more important matters. *phew*

fantastic, that's great news! I'll test out the release and debug versions of both 2.4.1e and 2.5.0b tomorrow, as well as the Unit Tests on Visual Studio 2003.

thanks
Pratty

The Unit Tests all pass for me on vs2003 and vs2005.

I'm still having problems with different results between debug and release
versions of the code using the Angelscript library, but its beginning to look like bad optimizations on behalf of Visual Studio. Its only happening with Global Optimizations turned on.

the vs2005 optimizer will also optimize inline assembly code. This might be related.

I've had problems with the optimizer in MSVC6 before. To fix those problems I had to change the C++ code slightly. Mainly it had to do with the ++ operators, that may not be evaluated in the same order when optimized.

Maybe if you could show where you're having problems with different results, then I could help you figure out how to fix them.

I've found the problem finally :)

Its in the implementation of variable declaration plus assignment statements in the 2.5.0b AngelScript parser, where implicit type conversion is required.


Take the following line of Angelscript code:

double myvar = 180;

In Angelscript 2.4.1e, the variable myvar has a value of 180.0.
In Angelscript 2.5.0b, the variable myvar has a value of 8.89318e-322.

I can get round this error at the moment by changing the decl + assignment
to be :

double myvar = 180.0;

cheers
Pratty

[Edited by - pratty on February 7, 2006 5:37:14 PM]

I've also found a bug in boolean comparison in version 2.5.0b.

Take the following statement.

bool flag = false;
bool otherFlag = flag == false;

In 2.4.1e, the value of otherFlag is true.
In 2.5.0b, the value of otherFlag is false.

I have worked around this problem by using the following syntax, which works on both versions:

bool flag = false;
bool otherFlag = not flag;

regards
Pratty

Ah, thanks for figuring out how to reproduce the problems.

The first problem, with the declaration with initialization, looks like the problem that villemon had here. Maybe the fix that I provided for him will work for you as well.

The second problem, also sounds familiar to me.

Anyway, I'll verify both of these and add them to the regression tests so that I do not break them again in the future.

Regards,
Andreas

Pratty,

I've not been able to reproduce these last problems you noticed.

The bug with the double value only happens if the variable is declared with const, without const the variable is correctly initialized. Are you sure you were not testing with const?

The comparison of boolean values also seems to work just fine for me. Would it be possible for you to send me a small test case that reproduces the bug?