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.
AngelScript 1.10.0 WIP 6 (2004/10/31)
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.
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
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.
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
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.
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
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):
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?
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
