Sorry, but it's
really time for a reality check here.
Really.You essentially argue that since TCL is an interpreted language, and since an interpreter is usually implemented in a certain way in C, and since the FF7 scripting language must be run through an interpreter, the FF7 scripting language must be based on TCL! Amazing deduction here. You've incidentally also proven that
all interpreted languages are TCL-based. Guess we should notify someone?
So for the reality check. TCL is an extremely generic text substitution based scripting language, which can relatively easily be tied into other programs via simple hooks. It allows you to dynamically define and redefine just about anything, and it has built-in support for various high-level concepts. TCL is based on the same sort of thinking that's behind LISP, i.e. maximum genericity.
This is what we know about the FF7 scripting language: It is extremely specific and minimalistic. It is not extensible. It is very low-level with minimal support for even basic program flow control constructs. It is compiled into bytecode (and the bytecode allocation shows clear signs of emergent development, i.e. the command set has changed during development). The FF7 scripting language is based on the same sort of thinking that's behind assembly language, i.e. maximum performance through simplicity.
So essentially claiming FF7's language to be based on TCL is like claiming that assembly language uses LISP.
Speaking as someone with some experience with both FF7's actual low-level internals
and with compilers, I can state with calm certainty that the FF7 scripting language
isn't a "TCL-based extension", and furthermore I can be relatively certain it wasn't derived from, compiled from or compiled
with anything TCL-related. Here's what we
do know:
- The opcode names, by a pure fluke. The fact that they're named and arranged in a consistent manner (especially the language-related control codes) suggest that the language (or at least the compiler+interpreter) was designed from scratch. Anything premade or reused would certainly show signs of more general (and in FF7 unused) constructs littered throughout the opcode table, or signs of "computer thinking" in the allocation order. The unused/unimplemented opcodes also suggest that the language (or rather, the command set) evolved over time. The opcode allocation table was done by a human, I have no doubts about this.
- Repeating occurances of certain control opcode patterns, and the complete lack of "variations". This suggests a compiler with some support for higher-level constructs such as if-else and while, which would then be automatically translated into and compiled as their simpler multi-opcode constructs.
- The relatively few kinds of higher-level constructs found. Anything more advanced than if-else and while tend to be written individually to suit the current situation, with frequent variations. This suggests the compiler (and hence language) did not offer any higher-level constructs than those established above.
- The great variation and "cleverness" in the use of other opcodes. This suggests that the majority of all opcodes were accessible and used directly (hence the names).
- The design of "if" opcodes and the if-else/while constructs. The fact that these both use jump-aheads/jump-backs in a clear and consistent manner suggest that these were compiler-handled, which in turn means that the compiler had simple scope management support. We know nothing of the syntax of these scopes, if they were {}, if-end, indent-based or whatever.
- The extra "if"-style opcodes found later in the opcode table. This suggests that not only did they have control of the opcode allocation, but also of the language and compiler (since these opcodes are designed used in the same fashion as the "core" if opcodes). The fact that the language was extended in this low-level manner later in the development suggests that there was no high-level (read: TCL-style) assistance in extending the language or feature-set, rather that it was done by hand.
Presumably the compiler was rather minimalistic, parsing text and helping with simpler argument syntax (and the higher-level constructs mentioned earlier), but did nothing else. Are you suggesting that they went through the trouble of using a feature-rich scripting language like TCL, then went through the huge effort of disallowing and removing all of its useful features?
No, this is clearly a custom-made language, possibly with some inspiration drawn from earlier Square engines, but definitely still written from scratch. The original language they wrote the scripts in might have borrowed some simple syntax (such as pseudo if-else/while constructs, labels, comments, variable names etc.) from some other language, but this has since been compiled away and we know nothing about it. Though one can guess that since there are no "for" and "do" constructs, they probably didn't borrow from C syntax (since then it'd be natural to include these). The only thing we can guess with some certainty is that the code would probably look like:
CHAR 1
PXYZI 25 -13 14 2
SOLID 1
RET
IF #plotprogression >= 582
 PXYZI 48 -12 18 5
END
RET
That is, very simple and minimalistic, just enough to get the job done.
