AngelScript 1.10.0 WIP 6 (2004/10/31)

One more update!!!! Way to go......glad I still have'nt updated from 1.7.x though. will take the giant step when 1.10.0 comes out

EddHead: The more you wait, more work will be necessary to do the upgrade. Although for this latest version I'm trying to keep backwards compatibility.

I didn't compile the library in release mode before uploading the latest WIP. Lennart let me know that there is some problem when doing so, but fortunately the fix is easy: Just turn on language extensions in Visual C++.

I will try to make the library fully working without Microsoft's language extensions.

I've uploaded the second WIP of version 1.10.0.

This version brings a much improved ExecuteString() method. The improvements made to the function is:
- Calls to ExecuteString() can be recursive, i.e. ExecuteString() can call a function that in turn calls ExecuteString()
- The application can pass its own context to ExecuteString() for preparation and execution (or just preparation)
- ExecuteString() should work with multiple threads (I haven't tested this yet, but I don't see why not)
- Only one call to ExecuteString() and retrieve the asIContext for exception handling (pass a pointer to a variable that will receieve the context)
- GetContextForExecuteString() is deprecated.

The old functionality is still available by defining AS_DEPRECATED when compiling the library

I've improved the multithread code so that it now works with MinGW as well. I removed the include of windows.h by locally declaring the few functions needed for thread handling. std::map had to be replaced with my own code as I found that the STL library isn't all that well-working as it ought to be. Microsoft's implementation of the STL library doesn't compile when you turn off the language extensions, and MinGW's implementation causes run-time problems with other template codes. My own map class (found in as_map.cpp) isn't quite as well structured as STL's map, but it works. However, I will improve upon it and start using it for other purposes as well, for example for mapping strings to classes, which should improve script compile times as well.

Yes, I know of STLPort which is supposedly much better than any STL library that comes with the compilers, but I don't want to force people to download another library just to compile mine. I have been thinking about rewriting the interface of my classes to match those of STL though. That would make it possible to replace my implementation and save some bytes in the final application.

I also fixed a bug with SetArguments(). It didn't allow the application to pass a pointer to the memory where the script function should return application registered classes. Thanks goes to Thomas Suter for helping me discover that bug.

Regards,
Andreas Jönsson
Author of AngelScript

I'm actually using 1.9.2 at the moment, but didn't AS used to protect scripts from dereferencing null pointers? In the past I thought that AS just quietly aborted the script call if the script tried to dereference null, but now it goes ahead and crashes. Or am I wrong?

It could be a bug. Can you show me an example script that crashes?

Apparently it is only a problem with ExecuteString:

Data* p = 0;
p->GetId();

Tested it with normal scripts and they aborted fine...

It is a bug.

What is happening is that an exception is raised because of the null-pointer access. The crash happens when SetInternalException() is called. Because the functionID for ExecuteString is 65533 there is an illegal memory access with when calling GetScriptFunction(functionID).

If you're pressed for a bug fix you could simply check for this case and skip that call.

The bug was introduced in version 1.9.1 when I took out the line numbers from the bytecode and stored them in a separate array.

Here's the complete list of bug fixes available in version 1.9.2a and 1.10.0 WIP 3:

- bug fix: Subtraction was optimized as if it was associative (thanks Lennart Denninger)
- bug fix: SetArguments() failed for script functions that returns registered object types by value. (thanks Thomas Suter)
- bug fix: The application would crash if an exception was raised in ExecuteString() (thanks Joe "Desdemona" Wright)
- bug fix: GetFunctionName() and GetFunctionDeclaration() now works for the ExecuteString() function id as well.
- bug fix: The compiler didn't warn when passing uninitialized variables to function parameters (thanks Alain "abrken" Bridel)
- bug fix: Constructors with parameters could cause assertion failure in GenerateExceptionHandler(). (thanks Alain "abrken" Bridel)

I've started work on incorporating the x86 assembler VM that Andres Carrera (Lioric) sent me. I hope to have this done by this weekend. Then we will see what kind of performance improvement we will really get.

The VM would be a great AddOn, is there a possibility we could get a compiler like program which could be installed in VC++ (or any other IDE) to point out errors in the script during a pre-build process?

This way we make sure the code starts with a clean script.

If I had the time I would write one, but I don't have that time.

It shouldn't be that difficult though. Write a small console program that registers all the same functions and prototypes as your game, but use null pointers instead of the real function pointers. Then compile the script and make the necessary verifications of the scripts. If the script doesn't compile correctly or is missing a necessary function you should end the application with returning non-zero from main(). That way nmake can recognize the compiler error and stop the build.

I should think that this would be the work of at most a couple of hours for a specific case like this.

To make it generic, using configuration files, etc, it would require a lot more time.

Hi

What is wrong with the actual built-in compiler? it has all the messages you will need in the build process and i dont see it why doing an external compiler will be better that using a code syntax library inside your editor

It will be better doing an stand alone compiler if you want to create a stand alone application with AS, extending AS from an embedable lib to a programing language tool

I think we better should focus on the debugger features of the lib, improving them and adding them

Take maxscript as an example, its a full featured script language, you can control over 99% of 3dsMax, but its a mess to debug it

I will work on adding debug hooks to AS very soon

Lioric

I've finally been able to get Lioric's assembler VM working with the latest WIP of 1.10.0. So far the increase in performance is only about 25%. This is because the new bytecodes introduced in version 1.9.x still haven't been converted to assembler, these bytecodes are the ones that are used the most. Once they are converted to assembler I expect the performance to be at least doubled.

I will hopefully be able to release another WIP this weekend, with the assembler VM working (although not fully optimized).

Those who are using MinGW, Dev/C++, DJGPP, GNUC, etc still won't be able to use the new VM though, as these compilers don't understand the intel syntax for inline assembly. If anyone feel up to converting the intel syntax to the AT&T syntax used by GNUC I would appreciate it very much.

Just thought I'd let you know how the work is going.

Hi


you know im here if you need help converting the new bcodes to asm

why so low improve in perfomance, keep in mind that if you benchmark all the script lib, from compile to execute, you are including the symbol relocation in the benchmark, you should time only the abstract machine execution, and because the vm's differences, the performance increase should be in the order of x not in %, like 1.5 x or 2x

Best Regards,

Lioric

Yes, I know you have offered your help. And you'll get your chance when I release the next WIP.

I only time the actual execution, so I'm sure the numbers are right. But don't worry, the improvement will go up as the rest of the bytecode instructions are converted to asm. If you're interested, you can download the performance test that I make in the latest WIP from the site.

The low performance improvement can probably be explained with that most of the bytecodes that are currently run are actually written in C++. Thus they only benefit from the relocation table that you created. Some bytecodes had changed so much with 1.9.x that I simply put in the C++ code instead of your assembler code, others are completely new and substitute the bytecodes that you had written in assembler.

I have concentrated on getting things to work and cleaning up the code. I haven't actually done any conversion to assembly myself. Before I release the next WIP I will make the saving/loading of bytecode work again with the new assembly VM.

Regards,
Andreas

PS. I'd like to thank you once more for this great contribution.

Fellow readers,

I've uploaded the latest WIP of 1.10.0. This version includes Andres Carrera's assembler optimized virtual machine. It's not fully optimized yet though, as he based the VM on AngelScript version 1.8.2, and there's been a lot of changes to the VM since then. The assembler VM is currently slightly less than 1.5x faster than the C++ version, I suspect that this will go up as the VM is optimized more over time.

It's not an easy task to optimize assembler though. Sometimes, when I converted a bytecode implementation from C++ to assembler the performance decreased as well, showing that at times it is simply easier to let the C++ compiler do the optimization for you. And sometimes when substituting two assembler instructions for one that did the same thing the performance also decreased, even though logically it should have improved. This is probably due to the processor's ability to pipeline instructions, and even parallel execution in some cases.

To use the assembler VM you need to compile the library with the flag USE_ASM_VM defined. Note that the assembler VM is only available for compilers that understand the intel assembler syntax. Once the assembler VM is more stabilized I will work on converting the code to AT&T syntax for the GNUC based compilers. Also note that the assembler VM hasn't been fully tested yet, as I've found that many of the instructions are never executed by my test cases.

I will now concentrate on implementing support for native arrays, and also writing testcases to cover the rest of the bytecode instructions.

Regards,
Andreas Jönsson
Author of AngelScript

Hm, not sure if this can be called a bug, but the following just happened to me. Something seemed to go wrong, but I couldn't find it as no error messages were given or anything.

This is some code I wrote to test this (Class 1 doesn't do anything but contain the static Method, DebugStream just does a printf):

	DebugStream ds;	asIScriptEngine* scripts=asCreateScriptEngine(ANGELSCRIPT_VERSION);	//Error here, of course, class not defined	scripts->RegisterGlobalFunction("Class1* GetClass1()",asFUNCTION(Class1::Get),asCALL_CDECL);	scripts->RegisterObjectType("Class1",0,0);	char* testcode="gjeskjhgskjegh";	scripts->AddScriptSection("test","test",testcode,strlen(testcode));	scripts->Build("test",&ds);	scripts->ExecuteString("test","gjngksejng",&ds);	scripting->Release();

Now, I know I should have checked the return value of the Register-stuff for errors, I just didn't because I was only going to test some stuff, but the problem is that after the RegisterGlobalFunction fails, all the rest just seems to fail silently.
If I switch around the declarations into correct oder, it works just as it should and complains that it can't compile nor execute that gibberish.

I admit that code like this shouldn't make it into any real programs, but some kind of error message would be nice, at least. Or is there something completely different that I am doing wrong?

AHHHHHHHHHHHHHHH!

I just spent the last hour hour trying to figure out why I couldnt get some simple scripts to work.

I had forgotten to remove the "Data* p = 0; p->GetId();" (previous post) from one of the related scripts and it was causing AS to silently abort....

twitch...

I think I shall take this moment to properly display notifications when AS experiences an exception... Something that should have been done long ago... hehe

Quote:

Original post by Wuntvor I admit that code like this shouldn't make it into any real programs, but some kind of error message would be nice, at least. Or is there something completely different that I am doing wrong?

You should AT LEAST test the return value from ExecuteString, I'm sure it gives asINVALID_CONFIGURATION witch means : "Hey man, I cannot compile your code since you have made something wrong with the library BEFORE compiling".

AbrKen