Hi, Firstly, great job with AngelScript. I've been using it quite extesively in some simulation software that requires pretty high runtime performance. I made the change from lua to angelscript 2.4.1d due to a quite significant reduction in program execution time, and am trialling 2.5.0a for any speed improvements. I'm about to test the performance and accuracy of 2.5.0a vs 2.4.1d on the system, but alas, on running the built-in angelscript unit tests, I've found that they fail in release mode on Visual Studio .NET 2003 (i.e. vc 7.1 compiler). The tests all pass in debug mode. Does anyone else have the same unit test behaviour? One other interesting thing to note is that the angelscript library appears to cause floating point exceptions(if you unmask them with the _control87 function). Floating point optimizations in the vc 7.1 compiler have been causing me some grief at the moment, so I've been snooping around in the floating point exception handling domain a bit more than I would normally like :). thanks Pratty

If possible you should really look at getting one of the full versions. I don't think the express editions have the added code analysis through use of the /analyze switch.

/analyze does quite a lot, such as detecting usage of null pointers, uninitialized variables, etc.

I use angelscript(I've used all versions since 2.4.1a) with the Visual C++ 2003 Toolkit in release mode just fine, I have no idea why it would fail for you there.

yeah, I've no idea either really. I have been chasing up potential bugs with floating point optimization in the vc 7.1 compiler yesterday. After installing some hot fixes, the problem still remains.

I'm getting different simulation results in release and debug mode, and some floating point operations generate NaNs (Not a Number) in a somewhat random fashion. On top of that, I found some floating point exceptions in the Angelscript library as I mentioned earlier.

Here's some further info on the current exceptions that I've found:

Inexact floating point precision exception at as_array.h : line 123

119 template <class T>
120 void asCArray<T>::PushLast(const T &element)
121 {
122 if( length == maxLength )
123 Allocate(int(maxLength*1.5f) + 1, true);
124
125 array[length++] = element;
126 }

the conversion of the float back to the int seems to be causing it, but I'm not really sure why.

I'll chase up the other floating point exception, I've forgetten exactly where it was but it had something to do with assigning a asCTypeInfo to another asCTypeInfo.


I'm in the process of using the library in AS_MAX_PORTABILITY mode, and generating wrapper functions that adhere to the void function(asIScriptGeneric *pGen) interface. The x86 stack manipulation code is a bit over my head (my x86 assembler skills are rubbish), so my hope is that I can debug the problem in portability mode a little easier.

thanks
Pratty

I should note that I'm having the Release / Debug conflicting behaviour in both 2.4.1d and 2.5.0a. It could quite possibly be to do with the memory management bugs highlighted in this thread :

http://www.gamedev.net/community/forums/topic.asp?topic_id=371843

I've built the angelscript libs (2.4.1d) with the AS_DEBUG preprocessor to get a dump of the VM code for each script. I've noticed that some of the scripts are different between debug and release builds. Only the instructions ALLOC, FREE, and OBJTYPE are different. Is that to be expected between debug and release builds? What is the OBJTYPE instruction doing?

I've included a short excerpt of one of the debug and release VM code dumps
that differs. Note the difference in ALLOC and OBJTYPE calls?

debug mode excerpt
-----------

0 0 * PUSH 18
- 5,1 -
6 18 * SUSPEND
10 18 * PSF 1
16 19 * OBJTYPE 0x7e53e8 (i:8279016, f:1.16014e-038)
24 20 * SET4 0xc (i:12, f:1.68156e-044)
32 21 * ALLOC 3365176, -2
44 18 * SET8 0x402319999999999a (i:4621565790109931930, f:9.55)
56 20 * PUSHZERO
60 21 * RDSF4 1
66 22 * CALLSYS -6 (int #array::?(uint))

release mode excerpt
--------------------

0 0 * PUSH 18
- 5,1 -
6 18 * SUSPEND
10 18 * PSF 1
16 19 * OBJTYPE 0xfe0a30 (i:16648752, f:2.33299e-038)
24 20 * SET4 0xc (i:12, f:1.68156e-044)
32 21 * ALLOC 3369448, -2
44 18 * SET8 0x402319999999999a (i:4621565790109931930, f:9.55)
56 20 * PUSHZERO
60 21 * RDSF4 1
66 22 * CALLSYS -6 (int #array::?(uint))

Did you do multiple runs of each?

It would seem that memory addresses would be likely to change between runs, thus why the different output in debug and release builds.. see if the output differs between multiple vm dumps in debug mode