gcs-bytecode.html 64 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831
  1. <P><PRE>
  2. **
  3. ** GCSx object structure and script bytecode format
  4. ** Revision: August 16, 2006 Alexis Janson:
  5. ** Added SENDT, SENDTs, QUERYT, QUERYTs (send/query when script type is known)
  6. ** Adding GET, GETs, GETT, GETTf, GETTs, GETTh, GETTa, GETTv
  7. ** Adding SET, SETs, SETT, SETTf, SETTs, SETTh, SETTa, SETTv
  8. **
  9. </PRE></P>
  10. <H3>GET [Stack]/[Local]/[Ptr](#) [String] [Stack](S)/[Local](S)/[Global](G) *@</H3>
  11. <H3>GET [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](c$) [Stack](S)/[Local](S)/[Global](G) *@</H3>
  12. <H3>GETs [Pop]/[Stack]/[Local]/[Ptr](c$) [String] [Stack](S)/[Local](S)/[Global](G) *@</H3>
  13. <H3>GETs [Pop]/[Stack]/[Local]/[Ptr](c$) [Pop]/[Stack]/[Local]/[Ptr](c$) [Stack](S)/[Local](S)/[Global](G) *@</H3>
  14. <H3>GETs [String] [String] [Stack](S)/[Local](S)/[Global](G) *@</H3>
  15. <H3>GETs [String] [Pop]/[Stack]/[Local]/[Ptr](c$) [Stack](S)/[Local](S)/[Global](G) *@</H3>
  16. <H3>GETT [Stack]/[Local]/[Ptr](#) [Int] [Int] [Int] *@</H3>
  17. <H3>GETT [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack]/[Local]/[Ptr](#) *@</H3>
  18. <H3>GETTf [Stack]/[Local]/[Ptr](#) [Int] [Int] [Float] *@</H3>
  19. <H3>GETTf [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack]/[Local]/[Ptr](%) *@</H3>
  20. <H3>GETTs [Stack]/[Local]/[Ptr](#) [Int] [Int] [String] *@</H3>
  21. <H3>GETTs [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack]/[Local]/[Ptr](c$) *@</H3>
  22. <H3>GETTh [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack]/[Local]/[Ptr](h) *@</H3>
  23. <H3>GETTa [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack]/[Local]/[Ptr](a) *@</H3>
  24. <H3>GETTv [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack](S)/[Local](S)/[Global](G) *@</H3>
  25. <H3>SET [Stack]/[Local]/[Ptr](#) [String] [Stack](S)/[Local](S)/[Global](G) *@</H3>
  26. <H3>SET [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](c$) [Stack](S)/[Local](S)/[Global](G) *@</H3>
  27. <H3>SETs [Pop]/[Stack]/[Local]/[Ptr](c$) [String] [Stack](S)/[Local](S)/[Global](G) *@</H3>
  28. <H3>SETs [Pop]/[Stack]/[Local]/[Ptr](c$) [Pop]/[Stack]/[Local]/[Ptr](c$) [Stack](S)/[Local](S)/[Global](G) *@</H3>
  29. <H3>SETs [String] [String] [Stack](S)/[Local](S)/[Global](G) *@</H3>
  30. <H3>SETs [String] [Pop]/[Stack]/[Local]/[Ptr](c$) [Stack](S)/[Local](S)/[Global](G) *@</H3>
  31. <H3>SETT [Stack]/[Local]/[Ptr](#) [Int] [Int] [Int] *@</H3>
  32. <H3>SETT [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack]/[Local]/[Ptr](#) *@</H3>
  33. <H3>SETTf [Stack]/[Local]/[Ptr](#) [Int] [Int] [Float] *@</H3>
  34. <H3>SETTf [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack]/[Local]/[Ptr](%) *@</H3>
  35. <H3>SETTs [Stack]/[Local]/[Ptr](#) [Int] [Int] [String] *@</H3>
  36. <H3>SETTs [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack]/[Local]/[Ptr](c$) *@</H3>
  37. <H3>SETTh [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack]/[Local]/[Ptr](h) *@</H3>
  38. <H3>SETTa [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack]/[Local]/[Ptr](a) *@</H3>
  39. <H3>SETTv [Stack]/[Local]/[Ptr](#) [Int] [Int] [Stack](S)/[Local](S)/[Global](G) *@</H3>
  40. <H1>0) Introduction</H1>
  41. <P>
  42. This document describes the exact internal structure of objects and code in a GCSx game. The exact structure and storage of an object script or function library is detailed from its original text (source) format, to pre-link bytecode format, (compiled when the code is saved) to fully-linked bytecode format, ready for game play.
  43. </P><P>
  44. When stored to a file, integer values are stored in Intel format (little-endian) and floating point values are stored in standard IEEE formats. Pointers are stored in whatever format and size is native to the platform being run on. Pointers are never saved to a file.
  45. </P>
  46. <H1>1) Object Structure</H1>
  47. <H2>1A) Global Variable Structure</H2>
  48. <P>
  49. Variables are stored as an 8-bit code that denotes the type of variable, and a 32-bit (or larger) value representing the variable. Integer and floating point values are stored as 32-bit values; strings, arrays, and hashes as pointers to more complex structures. String structures in memory are stored as either C-style NUL-terminated strings, or STL String objects, depending on circumstances. Array and hash structures include a reference count, counting the number of stack entries and variables that point to them.
  50. </P><P>
  51. The value or pointer for a variable is always in the same "place", regardless of variable type, so miscompiled code could accidentally read a pointer as an integer value, or vice-versa. Bytecode must be carefully compiled to know what value type will be present, or check this at runtime.
  52. </P><P>
  53. Variable type is 1 for integer, 2 for floating point, 4 for string, +8 for array, +16 for hash. An undefined variable will have a type of 0. This is not currently supported by the GCSx language directly, but can be used by certain bytecode constructs.
  54. </P>
  55. <H2>1B) Internal Stack Structure</H2>
  56. <P>
  57. Note that local variables of all types are stored on the stack.
  58. </P><P>
  59. An object stack can hold any number of items, accessed in a LIFO manner. An item consists of an 8-bit code denoting what that stack item contains, followed by a 32-bit value. (on platforms where pointers are larger than 32 bits, a stack value will be the size of a pointer instead.) Note that stack items and global variables have exactly the same format except for stack types 128, 129, and 130. Codes and values include-
  60. </P>
  61. <P><UL>
  62. <LI>0 - An undefined value (used only in very specific circumstances)
  63. <LI>1 - An integer value
  64. <LI>2 - A floating-point value
  65. <LI>4 - A pointer to a string, in the format of an STL String structure, which must be deallocated when removed from the stack
  66. <LI>+8 - A pointer to an array structure, which must be reference-checked; contains integers, floats, or strings
  67. <LI>+16 - A pointer to a hash structure, which must be reference-checked; contains integers, floats, or strings
  68. <LI>(reference-checking may result in deallocation if the stack entry was the last reference to the array or hash)
  69. <LI>128 - A function or code pointer, usually a return pointer; can be a NULL pointer (0) to signify stopping or no code
  70. <LI>129 - A pointer to an object waiting on a return value; more specifically, a pointer to a stack entry where the return value should be stored; can be a NULL pointer (0) to signify the object already got its value or does not need a value, but that this function was still called remotely and should not push the return value back to the stack. Unless NULL, will always point to a 130.
  71. <LI>130 - A pointer to an object that will eventually reply; more specifically, a pointer to the 129 stack entry within that object. Cannot be NULL. The eventual reply will replace this entry.
  72. </UL></P>
  73. <P>
  74. Most bytecode opcodes assume stack items are of a certain type, but the type of an element can be checked if necessary. This is mostly needed if you are clearing up the stack, as you must deallocate/dereference structures and release other objects waiting on return values (type 129) or objects that expect to reply (type 130).
  75. </P><P>
  76. When a function is called within an object (for whatever reason, internal or external) the stack should have an optional 129 entry defining where a return value should go if on another object, followed by zero or more parameters for the function, follwed by a 128 entry defining where the return will jump.
  77. </P>
  78. <H2>1C) Internal Object Structure</H2>
  79. <P>
  80. Internally, an object stores the following data-
  81. </P>
  82. <P><UL>
  83. <LI>A stack, including actual size (where to push items) and allocated size
  84. <LI>Amount of stack used by local variables
  85. <LI>Pointer to current instruction
  86. <LI>Object name, in string format
  87. <LI>Internal numeric ID
  88. <LI>ID of original codebase
  89. <LI>[link to sprite or onscreen representation]
  90. <LI>[other internal modes and settings as needed]
  91. </UL></P>
  92. <P>
  93. The actual, original code is stored elsewhere, and is not even loaded during gameplay. The bytecode is also stored elsewhere, as multiple objects can use the same bytecode.
  94. </P>
  95. <H2>1D) File Variable, Stack, Object Structures</H2>
  96. <P>(...notes on pointer storage/conversion...)</P>
  97. <H1>2) Function Library (and Codebase) Structure</H1>
  98. <P>
  99. A "function library" is used to store code that can be called from any object. A "codebase" is code that is assigned to one or more objects as their primary script. They are stored and structure almost identically.
  100. </P>
  101. <H2>2A) Internal Function Library (and Codebase) Structure</H2>
  102. <P>
  103. Internally, a function library or codebase stores the following data-
  104. </P>
  105. <P><UL>
  106. <LI>Library or codebase name, in string format
  107. <LI>Unique internal ID
  108. <LI>Size of bytecode
  109. <LI>Bytecode
  110. <LI>A 32-bit unsigned integer containing the count of [Ptr] links that need to be adjusted
  111. <LI>An array of links- (see bytecode pre-link for details on how this is used)
  112. <UL><LI>A 32-bit unsigned integer containing the exact offset where the 32-bit [Ptr] value is stored within the code block, with zero representing the first byte of code
  113. <LI>An 8-bit code, containing 0 for a global variable [Ptr], 1 for a built-in function [Ptr], 2 for a function library [Ptr]
  114. <LI>A string (NUL-terminated) containing the entirely-uppercase name of the global variable, internal function, or library function. Library functions can be written as the library name, followed by ::, followed by the function name, but this is not always necessary. (conflicting names will cause linking errors, however.)
  115. </UL>
  116. <LI>Original source code, during editing (this is discarded or not loaded during gameplay)
  117. <LI>Array of pointers, parameter lists, and names for each function within the library or codebase; these point directly into parts of the bytecode
  118. </UL><P>
  119. <H2>2B) File Function Library (and Codebase) Structure</H2>
  120. <P>(...notes on pointer storage/conversion...)</P>
  121. <H2>2C) Built-In Function Library Codebase</H2>
  122. <P>
  123. All built-in functions are C++ functions, accessed using the CALL opcode. However, QUERY, SEND, and SUBRs can only jump to bytecode- not directly to a C++ function. To allow these opcodes to call C++ functions, a special wrapper codebase is generated containing bytecode for calling each built-in function, and this bytecode is referenced during QUERY, SEND, and SUBRs opcode handling. Each wrapper is simply a PRECALL, CALL, and RET sequence.
  124. </P>
  125. <H1>3) Text Source Format</H1>
  126. <P>
  127. "Text source" is the code for a script or function in its original, human-readable format.
  128. </P>
  129. <H2>3A) Internal Text Source</H2>
  130. <P>
  131. The complete size of the text source is stored as a 32-bit integer. Text source is stored as a sequence of NUL-terminated strings. Each string is a single line of code. No newlines are stored. Nothing related to syntax coloring is stored.
  132. </P>
  133. <H2>3B) File Text Source</H2>
  134. <P>
  135. The complete size of the text source is stored as a 32-bit integer, followed immediately by the text source in the same format as internally.
  136. </P>
  137. <H1>4) Compiled Bytecode Format</H1>
  138. <P>
  139. "Bytecode" is a compiled form of code, designed to be quickly interpreted by the GCSx game engine. Whenever code for an object or function library is edited and saved, bytecode is compiled. This bytecode is kept stored in memory and as part of the world file in a "pre-link" state. This bytecode is mostly compiled, but not quite ready to be used. When the game is played, the code is "linked", which combines all loaded code and function libraries into a ready-to-use codebase. The resulting bytecode is in "post-link" format.
  140. </P>
  141. <H2>4A) Linking Process</H2>
  142. <P><UL>
  143. <LI>Load all object code and function libraries that will be used into internal structures
  144. <LI>If current platform uses non-32-bit pointers, scan all code and adjust [Ptr] operands to appropriate size; adjust [Offset] and [String] operand values to match; adjust function and codebase library pointers to match. This is done by actually interpreting the bytecode to know which operands to adjust, hence is relatively slow- this is only relevant on 64-bit or higher architectures, however, and is unlikely to ever matter
  145. <LI>Scan the link headers for all code to determine the names of all global variables used; create storage for all unique global variables and determine pointers for them
  146. <LI>Determine pointers for all library functions and built-in functions
  147. <LI>Link all object code, by inserting these pointers into the code based on the linking headers
  148. </UL></P>
  149. <H2>4B) Internal Function Library (and Codebase) Structure - Post-link</H2>
  150. <P>
  151. After linking, the array of link data is cleared, as is any original source code if present. The array of function names is kept, for dynamic function lookup during gameplay.
  152. </P>
  153. <H1>5) Bytecode</H1>
  154. <P>
  155. This section describes how the bytecode works. Note that bytecode is highly optimized for speed, and hence when not in debugging mode, few safety checks are performed.
  156. </P>
  157. <H2>5A) Registers</H2>
  158. <P>
  159. Although bytecode looks similar to assembly, there are no registers. (other than the code and stack pointers, to draw assembly parallels) All operations work via the stack.
  160. </P>
  161. <H2>5B) Operand Types</H2>
  162. <P>
  163. The following types of operands are available to bytecode commands, also known as bytecode opcodes. Operands marked with * may not have their final value determined until post-link. All operands are 32 bits wide except on platforms with pointers larger than 32 bits.
  164. </P>
  165. <H3>5B1) [Int]</H3>
  166. <P>
  167. A 32-bit signed integer value.
  168. </P>
  169. <H3>5B2) [Float]</H3>
  170. <P>
  171. A 32-bit signed floating-point value.
  172. </P>
  173. <H3>5B4) [Offset]*</H3>
  174. <P>
  175. A 32-bit signed integer value representing the number of 32-bit dwords to look or move forward or backward in the current code. Positive values move forward, negative move backward. A value of zero represents the current opcode. This value will be adjusted if the code size changes during linking- this will only occur if pointers larger than 32 bits are used by the current system.
  176. </P>
  177. <H3>5B3) [String]*</H3>
  178. <P>
  179. Same as [Offset], but contains an offset to a location containing a static string stored within the bytecode. At this location is a NUL-terminated string. Strings are typically stored at the end of bytecode. This value will be adjusted if the code size changes during linking- this will only occur if pointers larger than 32 bits are used by the current system.
  180. </P>
  181. <H3>5B5) [Ptr]*</H3>
  182. <P>
  183. A pointer to a memory location. A 32-bit placeholder is stored during pre-link, and during the linking process, an actual pointer to a memory location is stored here. This points to either a built-in (coded in C++) function, a library (bytecode) function, or a global variable. If linked on a system that uses pointers of a size other than 32 bits, this field will expand as necessary, and all [Offset] and [String] values will adjust accordingly.
  184. </P>
  185. <H3>5B6) [Local]</H3>
  186. <P>
  187. A 32-bit unsigned integer value that references a stack entry from the bottom-up. 0 references the first added stack entry; 1, the next, and so on. This is used to access non-scoped local variables.
  188. </P>
  189. <H3>5B6) [Stack]</H3>
  190. <P>
  191. A 32-bit unsigned integer value that references a stack entry from the top-down. 0 references the most recently added stack entry; 1, one entry back, and so on.
  192. </P>
  193. <H2>5C) Bytecode Command Format</H2>
  194. <P>
  195. Each bytecode command consists of-
  196. </P>
  197. <P><UL>
  198. <LI>A packed opcode containing addressing modes-
  199. <UL><LI>Lowest 8-bits represent the base opcode
  200. <LI>Consecutive 10-bit codes that represent opcode addressing modes for up to three operands (basically, which type of operand is present)
  201. <LI>Note that the third operand mode can only be 4 bits.
  202. </UL>
  203. <LI>Zero to three operands for that opcode, in order, stored per the above operand definitions and addressing modes selected. All operands are 32-bits unless on a platform with larger pointers.
  204. </UL></P>
  205. <H2>5D) Opcode Addressing Modes</H2>
  206. <P>
  207. Addressing modes allow one opcode to function in many ways; in addition, it allows the bytecode interpreter to prepare the operands before selecting a generic routine to perform. For example, although stack entries and global variables are accessed in different ways, the data itself is still the same, so a direct pointer to the data can be created and used to allow the same code to write to a stack entry or a variable. This also allows all debugging checks and assertions to be centralized.
  208. </P><P>
  209. All addressing modes return a pointer to an area of memory or structure containing the data, to be directly read or modified by the bytecode processor.
  210. </P><P>
  211. Each addressing mode is listed as the numeric value associated with it, as well as codes used to clarify which addressing modes apply to each format in the opcode reference, for [Stack], [Ptr], and [Local] operands. Also listed is what the entry is translated to at runtime before running the opcode.
  212. </P><P>
  213. Remember that [Local] mode is zero-based- 0 points to the bottom stack entry. [Stack] is also zero-based- 0 points to the top stack entry. [Offset] and [String] are zero-based- 0 points to the current opcode- and measured in 32-bit dwords.
  214. <P><UL>
  215. <LI>0 - No operand
  216. <LI>1 (#) - [Int] Integer literal (operand is the actual literal, should not modify) Translates to a pointer to the literal.
  217. <LI>2 (%) - [Float] Floating-point literal (operand is the actual literal, should not modify) Translates to a pointer to the literal.
  218. <LI>3 - [Offset] Offset to code location; Translates to a pointer to the code.
  219. <LI>4 ($) - [String] Offset to string literal (should not modify offset or literal) Translates to a pointer to the NUL-terminated string.
  220. <LI>5 (B) - [Ptr] Pointer to built-in function
  221. <LI>6 (F) - [Ptr] Pointer to library function
  222. <LI>7 (reserved- unused)
  223. <LI>8 (a) - An array of any type (use with +32/+64/+96 only)
  224. <LI>+8 (a#%$) - Used with 1/2/4 and +32/+64/+96 to signify an array structure of a specific type (CURRENTLY NEVER USED)
  225. <LI>16 (h) - A hash of any type (use with +32/+64/+96 only)
  226. <LI>+16 (h#%$) - Used with 1/2/4 and +32/+64/+96 to signify a hash structure of a specific type (CURRENTLY NEVER USED)
  227. <LI>+24 (#%$) - [Pop] Operand is ignored. Top stack entry contains data of given type, which is immediately popped, and discarded afterwards (points to actual data) Translates to a pointer to the actual data. (if a string, to the internal String structure) If two operands are [Pop], then the first value popped applies to the first operand, the second to the second. Popping for [Pop] occurs before any popping from the command itself, but is processed in operand order- i.e. a [Stack] entry will refer to the stack pre-pop if the [Stack] operand is before the [Pop] operand, or to the stack post-pop if the [Pop] operand is before the [Stack] operand.
  228. <LI>32 (S) - [Local] Index of local variable, unknown type, to be modified directly (points to stack entry, not its data) Translates to a pointer to the stack entry.
  229. <LI>+32 (#%$) - [Local] Index of local variable containing data type (points to actual data) Translates to a pointer to the actual data. (if a string, to the internal String structure)
  230. <LI>64 (S) - [Stack] Index of stack entry, unknown type, to be modified directly (points to stack entry, not its data) Translates to a pointer to the stack entry.
  231. <LI>+64 (#%$) - [Stack] Index of stack entry containing data type (points to actual data) Translates to a pointer to the actual data. (if a string, to the internal String structure)
  232. <LI>96 (G) - [Ptr] Pointer to global variable, unknown type, to be modified directly (points to var, not its data) Translates to a pointer to the variable itself.
  233. <LI>+96 (#%$) - [Ptr] Pointer to global variable containing data type (points to actual data) Translates to a pointer to the actual data. (if a string, to the internal String structure)
  234. <LI>+128 (c) - Const; Used with $ to signify translation should result in a pointer to the NUL-terminated string; the resulting string should not be modified. Invalid when used with [String] or a non-$ datatype. Allows a single routine that can work on both [String] and normal ($) operands, as long as it isn't modifying the string.
  235. </UL></P>
  236. <H2>5E) Opcodes</H2>
  237. <P>
  238. This section describes the available bytecode commands available. Commands marked with * may cause a task switch. (switch to another object) Commands marked with @ may cause a preemption check- if the current object's timeslice has taken too long, a task switch may occur. Task switches will never occur at any other time. Each opcode is listed with all addressing modes it supports. Opcodes may have many variations for different data types- these variations are technically different opcodes, but will have the same name except for extra lowercase letters to denote type.
  239. </P><P>
  240. All opcodes automatically have asserts based on their addressing modes to verify that the proper type of data has been given or referenced for storage, and that it is valid and within any range or boundaries as appropriate. (for example, a stack index is asserted to be within the current size of the stack minus local variables.) Any additional assertions are listed with the opcode. Assertions are only checked when debugging is compiled into GCSx. Any assertions that mention the stack apply only to the non-local-variable portion of the stack. Other non-specific assertions are also made, such as a script running past the end of its codebase, or an invalid opcode or addressing mode or combination.
  241. </P><P>
  242. Unlike normal C assertions, these assertions merely cause the current object to stop running and produce an error message. They do not cause GCSx itself to exit.
  243. </P><P>
  244. All opcodes that have been utilized by the bytecode compiler have been <SPAN STYLE="background: yellow">highlighted</SPAN>. Current opcode count: 96
  245. </P>
  246. <H3 STYLE="background: yellow">ADD [Stack]/[Local]/[Ptr](#) [Int]</H3>
  247. <H3 STYLE="background: yellow">ADD [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  248. <P>Takes the integer value given, adds the second value, and stores it back at the given location.</P>
  249. <H3 STYLE="background: yellow">ADDf [Stack]/[Local]/[Ptr](%) [Float]</H3>
  250. <H3 STYLE="background: yellow">ADDf [Stack]/[Local]/[Ptr](%) [Pop]/[Stack]/[Local]/[Ptr](%)</H3>
  251. <P>Takes the floating-point value given, adds the second value, and stores it back at the given location.</P>
  252. <H3 STYLE="background: yellow">AND [Stack]/[Local]/[Ptr](#) [Int]</H3>
  253. <H3 STYLE="background: yellow">AND [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  254. <P>Takes the integer values given, performs a bitwise AND, and stores the new value back at the given location.</P>
  255. <H3>ARRAY [Stack]/[Local]/[Ptr](a) [Int]</H3>
  256. <H3>ARRAY [Stack]/[Local]/[Ptr](a) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  257. <P>
  258. Accesses the noted element of the array (the second operand is the index into the array) and pushes the element found onto the stack. If the desired element is outside the array bounds, an empty element (0, 0.0, or "") of the appropriate type is pushed.
  259. </P>
  260. <H3>CALL [Ptr](B) *</H3>
  261. <P>Asserts: PRECALL was previous instruction</P>
  262. <P>Asserts: Returned value is not undefined</P>
  263. <P>
  264. Transfers code execution to the given external/built-in function. [Ptr] points to an actual C++ function, of format "int function(Object* object, StackEntry* stacktop)".
  265. </P><P>
  266. This function returns non-zero if the cycle should be ended and the function should be called again next cycle. In this case, the code pointer does not move. The top stack location (from PRECALL) can be used by the function for temporary storage, so that it knows when it is being called repeatedly.
  267. </P><P>
  268. This function should return zero normally. The top stack location (from PRECALL) will contain the return value. The code pointer then moves to the next opcode normally.
  269. </P>
  270. <H3 STYLE="background: yellow">CONCAT [Stack]/[Local]/[Ptr]($) [String]</H3>
  271. <H3 STYLE="background: yellow">CONCAT [Stack]/[Local]/[Ptr]($) [Pop]/[Stack]/[Local]/[Ptr](c$)</H3>
  272. <P>Takes the string value given, concatenate the second value, and store back at the given location.</P>
  273. <H3 STYLE="background: yellow">COPY [Stack](S)</H3>
  274. <H3 STYLE="background: yellow">COPY [Local](S)</H3>
  275. <H3 STYLE="background: yellow">COPY [Global](G)</H3>
  276. <P>If the noted stack entry or variable is an array or hash, creates an entirely new copy and stores it in that location. Optimized so that if the noted hash or array only has one reference, nothing happens. If the noted entry is not an array or hash, nothing happens.</P>
  277. <H3 STYLE="background: yellow">CREATEARRAY [Int]</H3>
  278. <P>Asserts: Value is 1, 2, or 4</P>
  279. <P>
  280. Creates a new, empty array and pushes it onto the stack. The type of array created is determined by the value given- 1 for Integer, 2 for Float, 4 for String.
  281. </P>
  282. <H3 STYLE="background: yellow">CREATEHASH [Int]</H3>
  283. <P>Asserts: Value is 1, 2, or 4</P>
  284. <P>
  285. Creates a new, empty hash and pushes it onto the stack. The type of hash created is determined by the value given- 1 for Integer, 2 for Float, 4 for String.
  286. </P>
  287. <H3>DEBUG [Int] [Int]</H3>
  288. <P>States the current line and column number within the original source file, for debugging purposes. This opcode is only generated if debugging is enabled.</P>
  289. <H3 STYLE="background: yellow">DISCARD [Int]</H3>
  290. <H3>DISCARD [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  291. <P>Asserts: Count of items is not larger than current stack</P>
  292. <P>Pops the given number of items off of the stack and discards them. Strings are freed, arrays and hashes are dereferenced, pointers to objects waiting on return values return an empty value, and waiting-for-reply pointers (type 130) modify the target 129 to be a NULL pointer.</P>
  293. <H3 STYLE="background: yellow">DISCARDL [Int]</H3>
  294. <H3>DISCARDL [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  295. <P>Asserts: Count of items is not larger than current stack</P>
  296. <P>Asserts: Items being discarded are 0, 1, 2, or 128 types only </P>
  297. <P>Pops the given number of items off of the stack and discards them. No checking is done for strings, arrays, hashes, or return types. This is a faster version of DISCARD intended for use when you know the stack entries are simple values.</P>
  298. <H3 STYLE="background: yellow">DIV [Stack]/[Local]/[Ptr](#) [Int]</H3>
  299. <H3 STYLE="background: yellow">DIV [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  300. <P>Takes the integer value given, divides by the second value, and stores the dividend at the given location. Dividing by zero will produce an unpredictable value, but will not cause an error.</P>
  301. <H3 STYLE="background: yellow">DIVf [Stack]/[Local]/[Ptr](%) [Float]</H3>
  302. <H3 STYLE="background: yellow">DIVf [Stack]/[Local]/[Ptr](%) [Pop]/[Stack]/[Local]/[Ptr](%)</H3>
  303. <P>Takes the floating-point value given, divides by the second value, and stores the dividend at the given location. Dividing by zero will produce an unpredictable value, but will not cause an error.</P>
  304. <H3 STYLE="background: yellow">EQ [Pop]/[Stack]/[Local]/[Ptr](#) [Int]</H3>
  305. <H3 STYLE="background: yellow">EQ [Pop]/[Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  306. <P>Compares the two integer values given. If equal, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  307. <H3 STYLE="background: yellow">EQf [Pop]/[Stack]/[Local]/[Ptr](%) [Float]</H3>
  308. <H3 STYLE="background: yellow">EQf [Pop]/[Stack]/[Local]/[Ptr](%) [Pop]/[Stack]/[Local]/[Ptr](%)</H3>
  309. <P>Compares the two floating-point values given. If equal, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  310. <H3 STYLE="background: yellow">EQs [Pop]/[Stack]/[Local]/[Ptr](c$) [String]</H3>
  311. <H3 STYLE="background: yellow">EQs [Pop]/[Stack]/[Local]/[Ptr](c$) [Pop]/[Stack]/[Local]/[Ptr](c$)</H3>
  312. <P>Compares the two string values given. If equal, ignoring case, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  313. <H3 STYLE="background: yellow">FTOI [Stack](S)</H3>
  314. <P>Asserts: Stack entry is a floating-point value</P>
  315. <P>Converts the given floating-point value to an integer in-place.</P>
  316. <H3 STYLE="background: yellow">FTOS [Stack](S)</H3>
  317. <P>Asserts: Stack entry is a floating-point value</P>
  318. <P>Converts the given floating-point value to a string in-place.</P>
  319. <H3 STYLE="background: yellow">FORCEARRAY [Stack](S) [Int]</H3>
  320. <P>Asserts: Stack entry is a value or undefined value (not a 128, 129, or 130)</P>
  321. <P>Asserts: Value is 1, 2, or 4</P>
  322. <P>
  323. If the stack entry is an array of the proper type, nothing happens. Otherwise, it is replaced by a newly-created, empty array. The type of array created is determined by the value given- 1 for Int, 2 for Float, 4 for String. If the stack entry was an array of an improper type but could be converted, the newly-created array will contain the converted values.
  324. </P><P>
  325. The FORCE* commands are typically used after a QUERY* or SUBRs command, to ensure the return value of an unknown function matches the expected type.
  326. </P>
  327. <H3 STYLE="background: yellow">FORCEFLOAT [Stack](S)</H3>
  328. <P>Asserts: Stack entry is a value or undefined value (not a 128, 129, or 130)</P>
  329. <P>
  330. If the stack entry is a floating-point value, nothing happens. If the entry is an integer or string, it is converted to floating-point. Otherwise, it is replaced by a floating-point value with the value 0.0.
  331. </P>
  332. <H3 STYLE="background: yellow">FORCEHASH [Stack](S) [Int]</H3>
  333. <P>Asserts: Stack entry is a value or undefined value (not a 128, 129, or 130)</P>
  334. <P>Asserts: Value is 1, 2, or 4</P>
  335. <P>
  336. If the stack entry is a hash of the proper type, nothing happens. Otherwise, it is replaced by a newly-created, empty hash. The type of hash created is determined by the value given- 1 for Integer, 2 for Float, 4 for String. If the stack entry was a hash of an improper type but could be converted, the newly-created hash will contain the converted values.
  337. </P>
  338. <H3 STYLE="background: yellow">FORCEINT [Stack](S)</H3>
  339. <P>Asserts: Stack entry is a value or undefined value (not a 128, 129, or 130)</P>
  340. <P>
  341. If the stack entry is an integer, nothing happens. If the entry is a floating-point value or string, it is converted to an integer. Otherwise, it is replaced by an integer with the value 0.
  342. </P>
  343. <H3 STYLE="background: yellow">FORCESTRING [Stack](S)</H3>
  344. <P>Asserts: Stack entry is a value or undefined value (not a 128, 129, or 130)</P>
  345. <P>
  346. If the stack entry is a string, nothing happens. If the entry is a floating-point value or integer, it is converted to a string. Otherwise, it is replaced by an empty string.
  347. </P>
  348. <H3 STYLE="background: yellow">GE [Pop]/[Stack]/[Local]/[Ptr](#) [Int]</H3>
  349. <H3 STYLE="background: yellow">GE [Pop]/[Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  350. <P>Compares the two integer values given. If the first value is greater than or equal to the second, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  351. <H3 STYLE="background: yellow">GEf [Pop]/[Stack]/[Local]/[Ptr](%) [Float]</H3>
  352. <H3 STYLE="background: yellow">GEf [Pop]/[Stack]/[Local]/[Ptr](%) [Pop]/[Stack]/[Local]/[Ptr](%)</H3>
  353. <P>Compares the two floating-point values given. If the first value is greater than or equal to the second, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  354. <H3 STYLE="background: yellow">GEs [Pop]/[Stack]/[Local]/[Ptr](c$) [String]</H3>
  355. <H3 STYLE="background: yellow">GEs [Pop]/[Stack]/[Local]/[Ptr](c$) [Pop]/[Stack]/[Local]/[Ptr](c$)</H3>
  356. <P>Compares the two strings given. If the first string is greater than or equal to the second, ignoring case, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack. 8-bit ASCII collation is used, with lowercase letters sorting as if they were uppercase.</P>
  357. <H3 STYLE="background: yellow">GT [Pop]/[Stack]/[Local]/[Ptr](#) [Int]</H3>
  358. <H3 STYLE="background: yellow">GT [Pop]/[Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  359. <P>Compares the two integer values given. If the first value is greater than (but not or equal to) the second, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  360. <H3 STYLE="background: yellow">GTf [Pop]/[Stack]/[Local]/[Ptr](%) [Float]</H3>
  361. <H3 STYLE="background: yellow">GTf [Pop]/[Stack]/[Local]/[Ptr](%) [Pop]/[Stack]/[Local]/[Ptr](%)</H3>
  362. <P>Compares the two floating-point values given. If the first value is greater than (but not equal to) the second, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  363. <H3 STYLE="background: yellow">GTs [Pop]/[Stack]/[Local]/[Ptr](c$) [String]</H3>
  364. <H3 STYLE="background: yellow">GTs [Pop]/[Stack]/[Local]/[Ptr](c$) [Pop]/[Stack]/[Local]/[Ptr](c$)</H3>
  365. <P>Compares the two strings given. If the first string is greater than (but not equal to) the second, ignoring case, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack. 8-bit ASCII collation is used, with lowercase letters sorting as if they were uppercase.</P>
  366. <H3>HASH [Stack]/[Local]/[Ptr](h) [String]</H3>
  367. <H3>HASH [Stack]/[Local]/[Ptr](h) [Pop]/[Stack]/[Local]/[Ptr](c$)</H3>
  368. <P>
  369. Accesses the noted element of the hash (the second operand is the index into the hash) and pushes the element found onto the stack. If no matching element is found, an empty element (0, 0.0, or "") of the appropriate type is pushed.
  370. </P>
  371. <H3 STYLE="background: yellow">IFFALSE [Pop]/[Stack]/[Local]/[Ptr](#) [Offset] @</H3>
  372. <H3 STYLE="background: yellow">IFFALSEf [Pop]/[Stack]/[Local]/[Ptr](%) [Offset] @</H3>
  373. <P>If the value given is 0 or 0.0, transfers code execution to the given location.</P>
  374. <H3 STYLE="background: yellow">IFTRUE [Pop]/[Stack]/[Local]/[Ptr](#) [Offset] @</H3>
  375. <H3 STYLE="background: yellow">IFTRUEf [Pop]/[Stack]/[Local]/[Ptr](%) [Offset] @</H3>
  376. <P>If the value given is something other than 0 or 0.0, transfers code execution to the given location.</P>
  377. <H3 STYLE="background: yellow">INIT *</H3>
  378. <P>Asserts: INIT must be present in all objects (asserted at link-time)</P>
  379. <P>
  380. Variable initialization is done. All objects on all scenes get to run once cycle before the game actually starts, during which they are expected to initialize global and local variables and such. INIT marks the end of this segment of code, switching to the next object. This also takes the current stack depth and stores it as the count of local variables. If an object has no initialization code, INIT or STOP should be the first opcode. No restrictions or preemptions are placed on code that runs before INIT, so this code should not enter any infinite loops, etc. or the bytecode engine will hang.
  381. </P>
  382. <H3 STYLE="background: yellow">ITOF [Stack](S)</H3>
  383. <P>Asserts: Stack entry is an integer value</P>
  384. <P>Converts the given integer to a floating-point value in-place.</P>
  385. <H3 STYLE="background: yellow">ITOS [Stack](S)</H3>
  386. <P>Asserts: Stack entry is an integer value</P>
  387. <P>Converts the given integer to a string in-place.</P>
  388. <H3 STYLE="background: yellow">JUMP [Offset] @</H3>
  389. <P>Asserts: Valid-looking opcode at given location</P>
  390. <P>Transfers code execution to the given location.</P>
  391. <H3 STYLE="background: yellow">LE [Pop]/[Stack]/[Local]/[Ptr](#) [Int]</H3>
  392. <H3 STYLE="background: yellow">LE [Pop]/[Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  393. <P>Compares the two integer values given. If the first value is less than or equal to the second, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  394. <H3 STYLE="background: yellow">LEf [Pop]/[Stack]/[Local]/[Ptr](%) [Float]</H3>
  395. <H3 STYLE="background: yellow">LEf [Pop]/[Stack]/[Local]/[Ptr](%) [Pop]/[Stack]/[Local]/[Ptr](%)</H3>
  396. <P>Compares the two floating-point values given. If the first value is less than or equal to the second, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  397. <H3 STYLE="background: yellow">LEs [Pop]/[Stack]/[Local]/[Ptr](c$) [String]</H3>
  398. <H3 STYLE="background: yellow">LEs [Pop]/[Stack]/[Local]/[Ptr](c$) [Pop]/[Stack]/[Local]/[Ptr](c$)</H3>
  399. <P>Compares the two strings given. If the first string is less than or equal to the second, ignoring case, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack. 8-bit ASCII collation is used, with lowercase letters sorting as if they were uppercase.</P>
  400. <H3 STYLE="background: yellow">LT [Pop]/[Stack]/[Local]/[Ptr](#) [Int]</H3>
  401. <H3 STYLE="background: yellow">LT [Pop]/[Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  402. <P>Compares the two integer values given. If the first value is less than (but not or equal to) the second, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  403. <H3 STYLE="background: yellow">LTf [Pop]/[Stack]/[Local]/[Ptr](%) [Float]</H3>
  404. <H3 STYLE="background: yellow">LTf [Pop]/[Stack]/[Local]/[Ptr](%) [Pop]/[Stack]/[Local]/[Ptr](%)</H3>
  405. <P>Compares the two floating-point values given. If the first value is less than (but not equal to) the second, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  406. <H3 STYLE="background: yellow">LTs [Pop]/[Stack]/[Local]/[Ptr](c$) [String]</H3>
  407. <H3 STYLE="background: yellow">LTs [Pop]/[Stack]/[Local]/[Ptr](c$) [Pop]/[Stack]/[Local]/[Ptr](c$)</H3>
  408. <P>Compares the two strings given. If the first string is less than (but not equal to) the second, ignoring case, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack. 8-bit ASCII collation is used, with lowercase letters sorting as if they were uppercase.</P>
  409. <H3 STYLE="background: yellow">LOGAND</H3>
  410. <P>Asserts: Top two entries of stack are values (not 0, 128, 129, or 130)</P>
  411. <P>Pops the top two entries of the stack. If both are true, pushes an integer 1 onto the stack; otherwise, pushes an integer 0 onto the stack. "true" is considered to be anything but a 0 or 0.0 value.</P>
  412. <H3>LOGOR</H3>
  413. <P>Asserts: Top two entries of stack are values (not 0, 128, 129, or 130)</P>
  414. <P>Pops the top two entries of the stack. If either one is true, pushes an integer 1 onto the stack; otherwise, pushes an integer 0 onto the stack. "true" is considered to be anything but a 0 or 0.0 value.</P>
  415. <H3 STYLE="background: yellow">MOD [Stack]/[Local]/[Ptr](#) [Int]</H3>
  416. <H3 STYLE="background: yellow">MOD [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  417. <P>Takes the integer value given, divide by the second value, and store the remainder back at the given location. Dividing by zero will produce an unpredictable value, but will not cause an error.</P>
  418. <H3 STYLE="background: yellow">MULT [Stack]/[Local]/[Ptr](#) [Int]</H3>
  419. <H3 STYLE="background: yellow">MULT [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  420. <P>Takes the integer value given, multiplys by the second value, and stores the product back at the given location.</P>
  421. <H3 STYLE="background: yellow">MULTf [Stack]/[Local]/[Ptr](%) [Float]</H3>
  422. <H3 STYLE="background: yellow">MULTf [Stack]/[Local]/[Ptr](%) [Pop]/[Stack]/[Local]/[Ptr](%)</H3>
  423. <P>Takes the floating-point value given, multiplys by the second value, and stores the product back at the given location.</P>
  424. <H3 STYLE="background: yellow">NE [Pop]/[Stack]/[Local]/[Ptr](#) [Int]</H3>
  425. <H3 STYLE="background: yellow">NE [Pop]/[Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  426. <P>Compares the two integer values given. If not equal, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  427. <H3 STYLE="background: yellow">NEf [Pop]/[Stack]/[Local]/[Ptr](%) [Float]</H3>
  428. <H3 STYLE="background: yellow">NEf [Pop]/[Stack]/[Local]/[Ptr](%) [Pop]/[Stack]/[Local]/[Ptr](%)</H3>
  429. <P>Compares the two floating-point values given. If not equal, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  430. <H3 STYLE="background: yellow">NEs [Pop]/[Stack]/[Local]/[Ptr](c$) [String]</H3>
  431. <H3 STYLE="background: yellow">NEs [Pop]/[Stack]/[Local]/[Ptr](c$) [Pop]/[Stack]/[Local]/[Ptr](c$)</H3>
  432. <P>Compares the two string values given. If not equal, ignoring case, pushes an integer 1 onto the stack. Otherwise, an integer 0 is pushed onto the stack.</P>
  433. <H3>NEG [Stack]/[Local]/[Ptr](#)</H3>
  434. <P>Takes the integer value given and negates it, storing the new value back at the given location. (negation results in the opposite sign)</P>
  435. <H3>NEGf [Stack]/[Local]/[Ptr](%)</H3>
  436. <P>Takes the floating-point value given and negates it, storing the new value back at the given location. (negation results in the opposite sign)</P>
  437. <H3>NOOP</H3>
  438. <P>Does nothing.</P>
  439. <H3>NOT</H3>
  440. <P>Asserts: Top entry of stack is a value (not 0, 128, 129, or 130)</P>
  441. <P>Pops the top entry of the stack. If it was true, pushes an integer 0 onto the stack; otherwise, pushes an integer 1 onto the stack. "true" is considered to be anything but a 0 or 0.0 value.</P>
  442. <H3 STYLE="background: yellow">OR [Stack]/[Local]/[Ptr](#) [Int]</H3>
  443. <H3 STYLE="background: yellow">OR [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  444. <P>Takes the integer values given, performs a bitwise OR, and stores the new value back at the given location.</P>
  445. <H3>PRECALL</H3>
  446. <P>Asserts: CALL is next instruction</P>
  447. <P>
  448. Pushes an undefined (different from 0) value onto the stack to hold CALL return information. Always used right before a CALL opcode.
  449. </P><P>
  450. This is done separate from the actual CALL so that the code pointer may remain pointed at the CALL instruction with no danger of multiple values being pushed onto the stack- PRECALL will cause one and exactly one return storage value to be pushed.
  451. </P>
  452. <H3 STYLE="background: yellow">POP [Stack]/[Local]/[Ptr](#)</H3>
  453. <P>Asserts: Top entry of stack exists and is an integer</P>
  454. <P>Asserts: Not popping to [Stack]0</P>
  455. <P>Pops an integer off the stack and stores it in the given location. Note for all POP opcodes- if storing to a stack entry, the position of the entry is "locked in" before the POP occurs, since addressing occurs before any command results.</P>
  456. <H3 STYLE="background: yellow">POPa [Stack]/[Local]/[Ptr](a)</H3>
  457. <P>Asserts: Top entry of stack exists and is an array</P>
  458. <P>Asserts: Destination is of same array type as array on top of stack</P>
  459. <P>Asserts: Not popping to [Stack]0</P>
  460. <P>Pops an array off the stack and stores it in the given location. The array already at the current location is dereferenced. Use COPY if you wish to make a new copy and not potentially reference an existing array.</P>
  461. <H3 STYLE="background: yellow">POPf [Stack]/[Local]/[Ptr](%)</H3>
  462. <P>Asserts: Top entry of stack exists and is a floating-point value</P>
  463. <P>Asserts: Not popping to [Stack]0</P>
  464. <P>Pops a floating-point value off the stack and stores it in the given location.</P>
  465. <H3 STYLE="background: yellow">POPh [Stack]/[Local]/[Ptr](h)</H3>
  466. <P>Asserts: Top entry of stack exists and is a hash</P>
  467. <P>Asserts: Destination is of same hash type as hash on top of stack</P>
  468. <P>Asserts: Not popping to [Stack]0</P>
  469. <P>Pops a hash off the stack and stores it in the given location. The hash already at the current location is dereferenced. Use COPY if you wish to make a new copy and not potentially reference an existing hash.</P>
  470. <H3 STYLE="background: yellow">POPs [Stack]/[Local]/[Ptr]($)</H3>
  471. <P>Asserts: Top entry of stack exists and is a string</P>
  472. <P>Asserts: Not popping to [Stack]0</P>
  473. <P>Pops a string off the stack and stores it in the given location. The string already at the current location is freed.</P>
  474. <H3 STYLE="background: yellow">POPv [Stack](S)</H3>
  475. <H3 STYLE="background: yellow">POPv [Local](S)</H3>
  476. <H3 STYLE="background: yellow">POPv [Global](G)</H3>
  477. <P>Asserts: Top entry of stack exists and is not a 0, 128, 129, or 130</P>
  478. <P>Asserts: If storing to a global, it is the proper type or a variant type</P>
  479. <P>Pops any type of value off the stack and stores it in the given location. Use COPY if you wish to make a new copy and not potentially reference an existing array or hash.</P>
  480. <H3>POPARRAY [Stack]/[Local]/[Ptr](a) [Int]</H3>
  481. <H3>POPARRAY [Stack]/[Local]/[Ptr](a) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  482. <P>Asserts: Top entry of stack exists and is of same type as array</P>
  483. <P>
  484. Accesses the noted element of the array (the second operand is the index into the array), pops the top value off of the stack, and stores the popped value into the noted element of the array. If the desired element is beyond the current range of the array, the array is extended until the new element will fit.
  485. </P>
  486. <H3>POPHASH [Stack]/[Local]/[Ptr](h) [String]</H3>
  487. <H3>POPHASH [Stack]/[Local]/[Ptr](h) [Pop]/[Stack]/[Local]/[Ptr](c$)</H3>
  488. <P>Asserts: Top entry of stack exists and is of same type as hash</P>
  489. <P>
  490. Accesses the noted element of the hash (the second operand is the index into the hash), pops the top value off of the stack, and stores the popped value into the noted element of the hash. A new element is created if one doesn't exist.
  491. </P>
  492. <H3 STYLE="background: yellow">PUSH [Int]</H3>
  493. <H3 STYLE="background: yellow">PUSH [Stack]/[Local]/[Ptr](#)</H3>
  494. <P>Takes the given integer and adds it onto the stack as the top item. Note for all PUSH opcodes- if copying from another stack entry, the position of the entry is "locked in" before the PUSH occurs, since addressing occurs before any command results.</P>
  495. <H3 STYLE="background: yellow">PUSHa [Stack]/[Local]/[Ptr](a)</H3>
  496. <P>Takes the given array and adds it onto the stack as the top item. Reference count is increased. Use COPY if you wish to make a new copy and not potentially reference an existing array.</P>
  497. <H3 STYLE="background: yellow">PUSHf [Float]</H3>
  498. <H3 STYLE="background: yellow">PUSHf [Stack]/[Local]/[Ptr](%)</H3>
  499. <P>Takes the given floating-point value and adds it onto the stack as the top item.</P>
  500. <H3 STYLE="background: yellow">PUSHh [Stack]/[Local]/[Ptr](h)</H3>
  501. <P>Takes the given hash and adds it onto the stack as the top item. Reference count is increased. Use COPY if you wish to make a new copy and not potentially reference an existing hash.</P>
  502. <H3 STYLE="background: yellow">PUSHs [String]</H3>
  503. <H3 STYLE="background: yellow">PUSHs [Stack]/[Local]/[Ptr](c$)</H3>
  504. <P>Takes the given string, copies it, and adds it onto the stack as the top item.</P>
  505. <H3 STYLE="background: yellow">PUSHv [Stack](S)</H3>
  506. <H3 STYLE="background: yellow">PUSHv [Local](S)</H3>
  507. <H3 STYLE="background: yellow">PUSHv [Global](G)</H3>
  508. <P>Takes the given stack entry or variable, copies it, and adds it to the stack as the top item. Works on all types of variables/stack entries. Use COPY if you wish to make a new copy and not potentially reference an existing array or hash.</P>
  509. <H3>QUERY [Stack]/[Local]/[Ptr](#) [String] [Int] *@</H3>
  510. <H3>QUERY [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](c$) [Int] *@</H3>
  511. <P>Asserts: [Int] entries exist on stack</P>
  512. <P>Asserts: Next instruction is WAIT</P>
  513. <P>
  514. This switches control to another object and calls a function of that object, then waits for a return value.
  515. </P>
  516. <P><UL>
  517. <LI>A number of stack entries equal to the third operand are removed from the current object's stack and remembered.
  518. <LI>(representing an unknown or unfilled return value)
  519. <LI>An object is located using the first operand as the object ID. If none is found, an undefined value is pushed onto the stack and nothing further occurs. Execution continues, skipping over the next WAIT opcode.
  520. <LI>An attempt is made to locate a function by the name given for the second operand. (function libraries and built-in functions, as well as the found object, are searched; object state is taken into account) If none is found, an undefined value is pushed onto the stack and nothing further occurs. Execution continues, skipping over the next WAIT opcode.
  521. <LI>If the located object has queueing enabled and is busy, the below data is pushed onto its queue instead of its stack.
  522. <LI>A "return value pointer" (type 129) is pushed onto the located object's stack (or queue), pointing to the top value on the current object's stack. A "reply waiting" (type 130) is pushed onto the current object's stack, pointing to the 129.
  523. <LI>A number of stack entries equal to the expected number of function parameters are pushed onto the located object's stack (or queue). These entries will be derived and converted from the remembered entries, dropping (and dereferencing) any excess entries or creating empty entries if not enough were present.
  524. <LI>If queueing, the function location is pushed onto the queue. Otherwise, the location of the instruction that the located object would normally run next is pushed onto the located object's stack (i.e., the located object's current code pointer) and control switches to the located object, at the given function.
  525. </UL></P>
  526. <P>
  527. The next opcode will be WAIT, to prevent resuming code execution until the top value of the stack is no longer type 130, signifying the located object has returned a value.
  528. </P>
  529. <H3>QUERYs [Pop]/[Stack]/[Local]/[Ptr](c$) [String] [Int] *@</H3>
  530. <H3>QUERYs [Pop]/[Stack]/[Local]/[Ptr](c$) [Pop]/[Stack]/[Local]/[Ptr](c$) [Int] *@</H3>
  531. <H3>QUERYs [String] [Pop]/[Stack]/[Local]/[Ptr](c$) [Int] *@</H3>
  532. <H3>QUERYs [String] [String] [Int] *@</H3>
  533. <P>Asserts: [Int] entries exist on stack</P>
  534. <P>Asserts: Next instruction is WAIT</P>
  535. <P>
  536. This command is the same as QUERY, except for the third step. Instead of locating an object by ID, an object matching the given name is located. If more than one match is found, one is chosen arbitrarily. (the first one found, although no order is defined)
  537. </P>
  538. <H3>QUERYT [Stack]/[Local]/[Ptr](#) [Ptr] [Int] [Int] *@</H3>
  539. <P>Asserts: Next instruction is WAIT</P>
  540. <P>Asserts: [Int] (last param) entries exist on stack</P>
  541. <P>Asserts: [Int] (third param) respresents a valid script id or zero</P>
  542. <P>Asserts: Parameter types have the proper, matching datatypes</P>
  543. <P>
  544. This is the same as QUERY, except a pointer directly to the target function is provided. The first [Int] represents the id of the script being called- this is used simply to verify that the target object is running the right script. This can be a zero value to signify that any script type is valid- this is only valid if [Ptr] points to within a function library.
  545. </P><P>
  546. The second [Int] represents the number of function parameters on the stack. It is assumed that the parameters are all of the proper type and count- no automatic parameter (or return value) conversion is done.
  547. </P>
  548. <H3>QUERYTs [Pop]/[Stack]/[Local]/[Ptr](c$) [Ptr] [Int] [Int] *@</H3>
  549. <H3>QUERYTs [String] [Ptr] [Int] [Int] *@</H3>
  550. <P>Asserts: Next instruction is WAIT</P>
  551. <P>Asserts: [Int] (last param) entries exist on stack</P>
  552. <P>Asserts: [Int] (third param) respresents a valid script id or zero</P>
  553. <P>Asserts: Parameter types have the proper, matching datatypes</P>
  554. <P>
  555. This is a combination of QUERYs and QUERYT. When searching for matching objects, only objects matching the given script id are 'found', unless the given script id is zero.
  556. </P>
  557. <H3>REPLY [Int] *</H3>
  558. <P>Asserts: Top entry of stack is a value (not a 0, 128, 129, or 130)</P>
  559. <P>Asserts: [Int] + 2 entries exist on stack</P>
  560. <P>Asserts: Stack entry pointed to by "object return value" pointer (if one is present) is type 130</P>
  561. <P>
  562. This returns a value to an object waiting on a return value. It is similar to RET in operation, without a code jump. [Int] represents the number of parameters and local variables currently on the stack.
  563. </P>
  564. <P><UL>
  565. <LI>The top stack entry is temporarily saved, and discarded.
  566. <LI>The entry now at stack position [Int] + 1 is examined. (0 being the current top entry after discarding the top entry)
  567. <LI>If this stack entry is an "object return value" pointer, (stack type 129) the saved value is stored at that location (if the pointer is not NULL) and the entry is changed to a NULL pointer. (still of type 129)
  568. </UL></P>
  569. <P>
  570. Control will switch if a valid object return value pointer was found, and that object switched control to the current object during the current cycle. This is handled internally by the bytecode interpreter and does not involve any state within the stack or object.
  571. </P>
  572. <H3>RET [Int] [Int] *</H3>
  573. <P>Asserts: Top entry of stack is a value (not a 0, 128, 129, or 130)</P>
  574. <P>Asserts: [Int] + [Int] + 2 entries exist on stack</P>
  575. <P>Asserts: 1 entry down is a code location</P>
  576. <P>Asserts: Stack entry pointed to by "object return value" pointer (if one is present) is type 130</P>
  577. <P>
  578. This returns from a "function call", using the top entry of the stack as the return value. [Int] represents the number of locals/temporaries currently on the stack and the number of parameters currently on the stack, respectively.
  579. </P>
  580. <P><UL>
  581. <LI>The top stack entry is temporarily saved and removed.
  582. <LI>[Int] (first operand) stack entrys are discarded. Note that any entries that reference strings, arrays, or hashes are deallocated/dereferenced.
  583. <LI>Code returns to the location stored in the top stack entry; that entry is also discarded. (A NULL pointer entry will result in code being stopped once this process is complete)
  584. <LI>[Int] (second operand) stack entrys are discarded. Again, entries are deallocated/dereferenced.
  585. <LI>The top stack entry is examined to see if it is an "object return value" pointer. (stack type 129) If it is, the saved return value is stored at that location (if the pointer is not NULL) and the top stack entry is discarded. If it is not, the saved return value is pushed onto the stack, unless code was stopped.
  586. <LI>If the top entry was ultimately not used (NULL pointer or code stopped) and it was a string, array, or hash, it is deallocated/dereferenced.
  587. </UL></P>
  588. <P>
  589. Control may switch back to another object in some situations. This happens when another object was waiting on the return value and switched control to the current object during the current cycle. This is handled internally by the bytecode interpreter and does not involve any state within the stack or object.
  590. </P>
  591. <H3>SEND [Stack]/[Local]/[Ptr](#) [String] [Int] *@</H3>
  592. <H3>SEND [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](c$) [Int] *@</H3>
  593. <P>Asserts: [Int] entries exist on stack</P>
  594. <P>
  595. This switches control to another object and calls a function of that object, but doesn't wait or accept a return value.
  596. </P>
  597. <P><UL>
  598. <LI>A number of stack entries equal to the third operand are removed from the current object's stack and remembered.
  599. <LI>An object is located using the first operand as the object ID. If none is found, nothing further occurs.
  600. <LI>An attempt is made to locate a function by the name given for the second operand. (function libraries and built-in functions, as well as the found object, are searched; object state is taken into account) If none is found, nothing further occurs.
  601. <LI>If the located object has queueing enabled and is busy, the below data is pushed onto its queue instead of its stack.
  602. <LI>A NULL 129 entry is pushed onto the located object's stack (or queue). [OPTIONAL]
  603. <LI>A number of stack entries equal to the expected number of function parameters are pushed onto the located object's stack (or queue). These entries will be derived and converted from the remembered entries, dropping (and dereferencing) any excess entries or creating empty entries if not enough were present.
  604. <LI>If queueing, the function location is pushed onto the queue. Otherwise, the location of the instruction that the located object would normally run next is pushed onto the located object's stack (i.e., the located object's current code pointer) and control switches to the located object, at the given function.
  605. </UL></P>
  606. <P>
  607. The current object will resume code execution if the located object finishes the function called before a task switch; otherwise, it will resume code execution at the next task switch. This is handled internally by the bytecode interpreter and does not involve any state within the stack or object.
  608. </P>
  609. <H3>SENDs [Pop]/[Stack]/[Local]/[Ptr](c$) [String] [Int] *@</H3>
  610. <H3>SENDs [Pop]/[Stack]/[Local]/[Ptr](c$) [Pop]/[Stack]/[Local]/[Ptr](c$) [Int] *@</H3>
  611. <H3>SENDs [String] [Pop]/[Stack]/[Local]/[Ptr](c$) [Int] *@</H3>
  612. <H3>SENDs [String] [String] [Int] *@</H3>
  613. <P>
  614. This command is the same as SEND, except for the second step. Instead of locating an object by ID, an object matching the given name is located. If more than one match is found, then each object has the steps applied individually, except that the stack entries are removed only once. Control switches to the first object affected. All objects affected get a task switch, in turn, before control returns to the original object.
  615. </P>
  616. <H3>SENDT [Stack]/[Local]/[Ptr](#) [Ptr] [Int] [Int]*@</H3>
  617. <P>Asserts: [Int] (last param) entries exist on stack</P>
  618. <P>Asserts: [Int] (third param) respresents a valid script id or zero</P>
  619. <P>Asserts: Parameter types have the proper, matching datatypes</P>
  620. <P>
  621. This is the same as SEND, except a pointer directly to the target function is provided. The first [Int] represents the id of the script being called- this is used simply to verify that the target object is running the right script. This can be a zero value to signify that any script type is valid- this is only valid if [Ptr] points to within a function library.
  622. </P><P>
  623. The second [Int] represents the number of function parameters on the stack. It is assumed that the parameters are all of the proper type and count- no automatic parameter (or return value) conversion is done.
  624. </P>
  625. <H3>SENDTs [Pop]/[Stack]/[Local]/[Ptr](c$) [Ptr] [Int] [Int]*@</H3>
  626. <H3>SENDTs [String] [Ptr] [Int] [Int]*@</H3>
  627. <P>Asserts: [Int] (last param) entries exist on stack</P>
  628. <P>Asserts: [Int] (third param) respresents a valid script id or zero</P>
  629. <P>Asserts: Parameter types have the proper, matching datatypes</P>
  630. <P>
  631. This is a combination of SENDs and SENDT. When searching for matching objects, only objects matching the given script id are 'found', unless the given script id is zero.
  632. </P>
  633. <H3 STYLE="background: yellow">SHIFTL [Stack]/[Local]/[Ptr](#) [Int]</H3>
  634. <H3 STYLE="background: yellow">SHIFTL [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  635. <P>Takes the integer value given, bitwise shifts left the amount of the second value, and stores the result back at the given location.</P>
  636. <H3 STYLE="background: yellow">SHIFTR [Stack]/[Local]/[Ptr](#) [Int]</H3>
  637. <H3 STYLE="background: yellow">SHIFTR [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  638. <P>Takes the integer value given, bitwise shifts right the amount of the second value, and stores the result back at the given location.</P>
  639. <H3 STYLE="background: yellow">STOF [Stack](S)</H3>
  640. <P>Asserts: Stack entry is a string value</P>
  641. <P>Converts the given string to a floating-point value in-place.</P>
  642. <H3 STYLE="background: yellow">STOI [Stack](S)</H3>
  643. <P>Asserts: Stack entry is a string value</P>
  644. <P>Converts the given string to an integer in-place.</P>
  645. <H3 STYLE="background: yellow">STOP *</H3>
  646. <P>Stop running entirely. The stack is cleared. Strings are freed, arrays and hashes are dereferenced, pointers to objects waiting on return values return an empty value, and waiting-for-reply pointers (type 130) modify the target 129 to be a NULL pointer. Control switches to the next object.</P>
  647. <H3 STYLE="background: yellow">STORE [Stack]/[Local]/[Ptr](#) [Int]</H3>
  648. <H3 STYLE="background: yellow">STORE [Stack]/[Local]/[Ptr](#) [Stack]/[Local]/[Ptr](#)</H3>
  649. <P>Takes the given integer and stores it at the given location.</P>
  650. <H3 STYLE="background: yellow">STOREa [Stack]/[Local]/[Ptr](a) [Stack]/[Local]/[Ptr](a)</H3>
  651. <P>Asserts: Source and destination are of same array type</P>
  652. <P>Takes the given array and stores it at the given location, increasing reference count and dereferencing the array previously there. Use COPY if you wish to make a new copy and not potentially reference an existing array.</P>
  653. <H3 STYLE="background: yellow">STOREf [Stack]/[Local]/[Ptr](%) [Float]</H3>
  654. <H3 STYLE="background: yellow">STOREf [Stack]/[Local]/[Ptr](%) [Stack]/[Local]/[Ptr](%)</H3>
  655. <P>Takes the given floating-point value and stores it at the given location.</P>
  656. <H3 STYLE="background: yellow">STOREh [Stack]/[Local]/[Ptr](h) [Stack]/[Local]/[Ptr](h)</H3>
  657. <P>Asserts: Source and destination are of same hash type</P>
  658. <P>Takes the given hash and stores it at the given location, increasing reference count and dereferencing the hash previously there. Use COPY if you wish to make a new copy and not potentially reference an existing hash.</P>
  659. <H3 STYLE="background: yellow">STOREs [Stack]/[Local]/[Ptr]($) [String]</H3>
  660. <H3 STYLE="background: yellow">STOREs [Stack]/[Local]/[Ptr]($) [Stack]/[Local]/[Ptr](c$)</H3>
  661. <P>Takes the given string and copies it at the given location, freeing the string currently there.</P>
  662. <H3 STYLE="background: yellow">SUB [Stack]/[Local]/[Ptr](#) [Int]</H3>
  663. <H3 STYLE="background: yellow">SUB [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  664. <P>Takes the integer value given, subtracts the second value, and stores the result back at the given location.</P>
  665. <H3 STYLE="background: yellow">SUBf [Stack]/[Local]/[Ptr](%) [Float]</H3>
  666. <H3 STYLE="background: yellow">SUBf [Stack]/[Local]/[Ptr](%) [Pop]/[Stack]/[Local]/[Ptr](%)</H3>
  667. <P>Takes the floating-point value given, subtracts the second value, and stores the result back at the given location.</P>
  668. <H3>SUBR [Offset] @</H3>
  669. <H3>SUBR [Ptr](F) @</H3>
  670. <P>Asserts: Valid-looking opcode at given location</P>
  671. <P>
  672. Push the location of the next instruction onto the stack, then transfer code execution to the given location. Note that, when the code returns, the top stack location will always contain a return value.
  673. </P><P>
  674. Unlike other methods of accessing functions, this one assumes the proper number and type of operands have already been pushed onto the stack.
  675. </P>
  676. <H3>SUBRs [Stack]/[Local]/[Ptr]($) [Int] @</H3>
  677. <P>Asserts: [Int] entries exist on stack</P>
  678. <P>(note- ($) could become (c$) if more efficient)</P>
  679. <P>
  680. This calls a function by name, adjusting the parameters on the stack as needed. This opcode is not affected by queueing.
  681. </P>
  682. <P><UL>
  683. <LI>An attempt is made to locate a function by the name given for the second operand. (function libraries and built-in functions, as well as the current object, are searched; object state IS NOT taken into account and state functions are only accessible explicitly using :: syntax) If none is found, an undefined value is pushed onto the stack and nothing further occurs.
  684. <LI>A number of stack entries equal to the third operand are removed from the stack and remembered.
  685. <LI>A number of stack entries equal to the expected number of function parameters are pushed onto the stack. These entries will be derived and converted from the remembered entries, dropping (and dereferencing) any excess entries or creating empty entries if not enough were present.
  686. <LI>The location of the instruction that would normally run next is pushed onto the stack.
  687. <LI>Control switches to the given function.
  688. </UL></P>
  689. <P>
  690. Note that, when the code returns, the top stack location will always contain a return value, which may be undefined.
  691. </P>
  692. <H3>SWAP [Stack](S) [Stack](S)</H3>
  693. <P>Asserts: Source and destination are actual data, not code, object return pointers, or undefined</P>
  694. <P>Takes the given stack entry and swaps it with another stack entry. No copying, freeing, or referencing is required.</P>
  695. <H3>TYPEOF [Stack](S)</H3>
  696. <H3>TYPEOF [Local](S)</H3>
  697. <H3>TYPEOF [Global](G)</H3>
  698. <P>
  699. Examines the type of entry or variable at the given location, and pushes an integer value onto the stack representing what it is. The value pushed matches the type values used for stack entries- 1 for integer, 2 for floating point, 4 for string, +8 for array, +16 for hash, 0 for undefined, 128 for code pointer, 129 for return value pointer, and 130 for reply waiting pointer.
  700. </P>
  701. <H3>WAIT *</H3>
  702. <P>Asserts: At least one entry on the stack</P>
  703. <P>Asserts: Previous instruction is a QUERY variant</P>
  704. <P>
  705. The code pointer will remain at this opcode until the top entry of the stack is no longer a type 130 value. This causes the object to wait for a RET or REPLY value immediately after a QUERY command.
  706. </P>
  707. <H3 STYLE="background: yellow">XOR [Stack]/[Local]/[Ptr](#) [Int]</H3>
  708. <H3 STYLE="background: yellow">XOR [Stack]/[Local]/[Ptr](#) [Pop]/[Stack]/[Local]/[Ptr](#)</H3>
  709. <P>Takes the integer values given, performs a bitwise XOR, and stores the new value back at the given location.</P>
  710. <H1>6) Bytecode Compilation</H1>
  711. <P>
  712. This section describes how the GCSx language translates into bytecode.
  713. </P>
  714. <H2>6A) Notes on Global Variables, Constants, and Function Libraries</H2>
  715. <P>
  716. Globals and function libraries define things outside of the code that they are referenced in. This is handled as follows-
  717. </P><P>
  718. All non-library code is first scanned for global constant and variable declarations, then all code is compiled. Unrecognized identifiers are treated as function library calls. Any missing functions will be noted during linking.
  719. </P><P>
  720. During editing, modifying the code of any object that contains (or contained before editing) global declarations will cause a recompile of all objects. Modifying a function library does not require any recompilation.
  721. </P>
  722. <H2>6B) Notes on Stack Usage</H2>
  723. <P>
  724. Many operations and calculations require judicious usage of the stack for temporary storage. During compilation, the current amount of temporary storage being used is carefully tracked line-by-line, opcode-by-opcode. This space is freed up as soon as the operations are complete. Certain structures such as if-else require temporary storage to remain on the stack for an extended block of code; this storage is freed at the earliest possible opportunity. If a goto exists in such a block, the temporary storage must be freed before the goto. If a label exists in such a block, any goto going to that label must first fill the stack with appropriate values matching the expected amount of temporary storage.
  725. </P><P>
  726. The stack is also used for all local and scoped variables.
  727. </P>