Over the past week, I've spent some of my time finishing up GameScript. I thought you might be interested in my latest progress.
Currently, GameScript is 98% functional (custom types, function, static vars, local vars, global vars, select case, while, wend, etc. etc.). The entire language works flawlessly. Luckily, I had to make almost no changes to the compiler when getting the VM to work. I simply need to add an assembly code optimizer, and (not so simple) arrays. I also will need to find a way to integrate the scripts with the application better.
When a runtime error occurrs, a runtime error window is displayed, after writing a CrashLog.txt file containing useful information about the crash, including a dis-assembled portion of the code where the error occurred.
Currently, it runs this script perfectly, giving a list of prime numbers:
My scripting engine currently runs at 3-5 times less than the same code directly compiled in a blitz EXE (both with debug mode off). Because of the structure of the VM (lots of nested Select..Case's because of the multi-variable type), running in debug mode causes scripts to run extremely slow (10 times slower than when debug mode is off). Anyway, I hope my optimizer will be able to increase efficiency and possibly get it down to an average of only 3 times slower.
I'm also thinking about making a debugger program to debug scripts. It would be very possible to create a simple app to allow you to step over/step into code from the original script file (if each instruction code has a line index to use).
Let me know if I can help in any way with your scripting engine.
P.S. When you get to functions, remember that local/global variables makes no difference to the VM. A global variable named "a", for example, is totally different from a local variable in some function named "a", since the compiler should automatically do this. When the compiler comes across "a", it checks what function it's in, and handles the compilation accordingly. Also, for recursion to work, all a functions variables should be "push"ed before calling any function, then "pop"ped after the function call.
Currently, GameScript is 98% functional (custom types, function, static vars, local vars, global vars, select case, while, wend, etc. etc.). The entire language works flawlessly. Luckily, I had to make almost no changes to the compiler when getting the VM to work. I simply need to add an assembly code optimizer, and (not so simple) arrays. I also will need to find a way to integrate the scripts with the application better.
When a runtime error occurrs, a runtime error window is displayed, after writing a CrashLog.txt file containing useful information about the crash, including a dis-assembled portion of the code where the error occurred.
Currently, it runs this script perfectly, giving a list of prime numbers:
'Prime number search Local prime:Int, i:Int Print "Prime Numbers:" prime = 1 For i = 1 To 20 prime = NextPrime(prime) Print prime Next End 'Prime number search function Function NextPrime:Int(current:Int) Local i:Int Local found:Int While Not found current = current + 1; Found = True For i = 2 To current-1 If (current Mod i) = 0 Then Found = False Exit EndIf Next Wend Return current EndFunction
My scripting engine currently runs at 3-5 times less than the same code directly compiled in a blitz EXE (both with debug mode off). Because of the structure of the VM (lots of nested Select..Case's because of the multi-variable type), running in debug mode causes scripts to run extremely slow (10 times slower than when debug mode is off). Anyway, I hope my optimizer will be able to increase efficiency and possibly get it down to an average of only 3 times slower.
I'm also thinking about making a debugger program to debug scripts. It would be very possible to create a simple app to allow you to step over/step into code from the original script file (if each instruction code has a line index to use).
Let me know if I can help in any way with your scripting engine.
P.S. When you get to functions, remember that local/global variables makes no difference to the VM. A global variable named "a", for example, is totally different from a local variable in some function named "a", since the compiler should automatically do this. When the compiler comes across "a", it checks what function it's in, and handles the compilation accordingly. Also, for recursion to work, all a functions variables should be "push"ed before calling any function, then "pop"ped after the function call.