Mrnaughty, as Seph has explained, scripting is rarely compiled into executable form. My XScape scripting engine does not compile into executables. The whole system is coded in C/C++ to acheive faster processing, but basically it is exactly as described above.
I parse my scripts using a textual recognition lexer that converts commands etc into OPcodes. An OPcode can be either a command or an expression index. Expressions are things like variable names, user defined function names, values or text entries ("text"). Command OPcodes, are integer bytes which reference an index into a function pointer table which stores the locations of the C/C++ functions to process that command.
So for example, the following piece of script code:
Dim nVar As Integer
nVar = 100
Would be converted to:
9057 - OPcode for DIMension
5 - Expression index, where the index table lists all variable entries, text etc. In this case, entry 5 is the name "nVar".
9022 - AS, checked by the preparser to ensure it's syntactically correct
9001 - INTEGER - Which from this point, a new Var entry is created for the current process scope. With the name, and type
9999 - Line terminator
5 - Expression index, since this is the first entry on this line, it is going to be an assignment of somesort, so a recursive descent algorithm is called to process the expression.
9100 - EQUAL operator
7 - Expression index, points to the value "100"
9999 - Line terminator.
Ok, this is a simplified example of what I do when processing script files, but the general point here is that instead of comparing values in your script like:
If Command$="DIM" Then
Which is hideously slow, because your actually doing a string comparison of 3 bytes, hence 3 cycles of the program execution etc, a VM or Virtual machine processor can do a check on the OPcode and call the function straight away because the function details are stored directly with the OPcode data - (In C/C++ anyway). It's a different kettle of fish in DBPro.
I did implement this kind of system with Thrust, an earlier attempt at a scripting system which was coded in DarkBASIC Professional native code. I did a hell of a lot of preparsing on the script files to get the best speed out of the system. The only two things that let it down was that scanning dynamic arrays, large ones to find an entry based on an index (not an array indice), was slow. Hash tables would have seriously benefited this system if they existed at the time.
All the OPcodes, their Textual equavalents etc, were stored in Data statements for each module, where a module was like Object, Sound, Entity, Image, Sprite etc.
They were stored like:
DATA "REM", OP_REM, ""
DATA "`", OP_REM, ""
DATA "CLS", OP_CLS, ""
...
...
DATA "TEXT", OP_TEXT, "II"
The third entry defined what the command operands were. In the case of TEXT, it was "II", or two integers.
Paul.
Home of the Cartography Shop - DarkBASIC Professional map importer
