Before anything, I know this message may seem like it does not apply to Pascal, but it does in terms of you the programmer's opinions on the interface of the script engine.
Thanks for the info Peter and Hans! I found Lex/Yacc for TP on ieec.com(?), it was a version from the "Dragon Book" translated from C to Pascal to generate Pascal code. The code generated by it did not compile with GPC (I'll send the code to Peter after I send this e-mail).
I ran into a couple of conflicts with my specs and was wondering if I could pick some of your brains. Below are the specs for the script object followed by the reasons for the specs and then my plans for the script executor object..
Major features as of this writing --------------------------------- = C language syntax, and built-in C functions, with minor deviations (no main(), write/writeln instead of printf/etc, read/readln instead of getc/scanf/etc, * for VAR parameters but no need to use & when calling the function) = Plain-text "modules" = No pointer operations, no file operations = Not case-sensitive = Type-casting
Reasons for each of the features -------------------------------- = Readibility -less words to keep track of (as opposed to begin, end, etc)-, no main function (to prevent user confusion, tho optional return will be supported to provide the program with an error code for the more savvy or for non-programming game designers), operator overloading, etc. = Plain-text to eliminate the need for "linking", script code that is not a declaration will not be compiled. If a script module needs to initialize it should provide an "init" function, modules will ignore "stray code" which would otherwise execute in the primary script. = Allows scripts to share data and declarations. = Not having pointer operations or file operations keeps hackers from ruining unsuspecting users, and eliminates the need to perform a security check on the byte-code compiled script (a la Java, ActiveX, etc) = Case-insensitivity ensures unique identifiers = Type-casting for practicality and flexibility
The part I'm trapped on is the language syntax. I'm thinking of having 2 script scanner objects, one a subset of C and the other a subset of Pascal. I'm also considering a hybrid between both languages, but the problem with that is that if you deviate too much from one or the other, the learning curve could increase. I'm also thinking of structuring the scanner so that source-level modifications will not be neccessary under normal circumstances, the way I'm planning on doing this is by allowing the programmer to add tokens of their own to the script language at run-time. Consider the following potential function as an example:
... TYPE TPlayer = OBJECT ... Action : Integer; ... END; VAR Player1 : TPlayer; ... Script.AddVar( tVar, 'i', 'Player1.Action', @Player1.Action); ...
In the above example, the scanner declares Player1 so that the user may not declare a variable or function with the same name. tVar - Tells the scanner that it is a variable, not a constant so it may be modified. 'i' - indicates that the variable is an Integer 'Player1.Action' - Tells the scanner how the variable is to be represented in the script. @Player1.Action - Address of variable where data is stored.
Enumerated types might be supported at run-time. There's no doubt at all that they are useful, but I think that if an enumerated type is to be passed, it should be coded in a descendant object rather than being implemented at run-time. I'm thinking of supporting enumerated types within the script object in terms of the user being able to define their own, but I don't know if that would be practical. If a function is to be added, AddFunction would be used.
Now for the script executor object. I want to have a fixed set of base opcodes so that no matter what language the scanner is written to handle, it will always execute the opcodes in the same way, this way 2 or more script scanners can be written to cater to the tastes of the end-user, but will execute the same. I'm thinking of reserving about 125 opcode ids and leaving 130 for user-defined functions, the downside to this is the need for version checking. If the compiled script version is newer than the script executor object, the script cannot be executed. In a way this is not a disavantage because even tho the unknown opcodes could be ignored, there could be stray parameters which would be misinterpreted as opcodes. Even if information is included about how many bytes to skip to get past them, the script will more than likely depend on those unknown opcodes.
The format of the "executable" will be the following: Version : Cardinal(16) -> BCD, 8 bits for the major rev, 8 for the minor CodeOffset : Cardinal(32) -> Offset past header where the code is DataOffset : Cardinal(32) -> Offset past header and code where the data is Code : Byte[?] ------> Compiled opcodes Data : Byte[?] ------> If data is present it will be stored here
Version is, as described before the format, used to determine whether or not the executor can run the compiled script. CodeOffset and DataOffset are present in case the header format changes, DataOffset is present because the code can vary in length. Code of course contains the opcodes to be executed. Data of course contains the data to be accessed by the code.
The Code and Data will be stored seperately in memory so that 2 seperate pointers can be used. Opcodes that access variables will consist of a byte code followed by an offset into the data followed by the length of the data (if a string operation such as writeln).
These plans are not set in stone, there will be a couple of changes, but I'm trying to keep in mind the end-user or non-programming game designer as much as the programmer.
Thanks in advance!
See ya! Orlando Llanes
"Hey, we all did the drug thing, we all did the money thing, and eventually you find out that none of that stuff fixes anything, and we have nowhere else to go except to evolve spiritually and intellectually" -- Meredith Brooks
"Look out fo' flyeeng feet" O__/ a010111t@bc.seflin.org /|____. O <__. /> / \ ____________|_________ http://ourworld.compuserve.com/homepages/Monkey414