Script compiling method, device, equipment, storage medium and product

Abstract

Provided are a script compiling method, device, equipment, storage medium and product. The method proposed herein includes: obtaining a first script file and environment definition information, the environment definition information indicating an interaction specification between the first script file and a host running environment; based on the environment definition information and the first script file, determining running data required for executing the first script file and a storage requirement of the running data; based on the storage requirement, determining a first storage location of the running data in a predetermined data space to obtain a memory layout of the first script file; and generating a first image file based on the memory layout, the first image file carrying layout description information used for determining the predetermined data space and being configured to access the running data according to the first storage location during execution, wherein the memory layout remains unchanged during execution of the first image file.

Description

Technical Field

[0001] The examples in this article generally relate to the field of computer science, and in particular to methods, apparatuses, devices, computer-readable storage media, and products for script compilation. Background Technology

[0002] In the field of game logic development, scripting is a widely adopted technique. While general-purpose scripting languages ​​offer hot-update capabilities and flexible expressive power, they still face technical challenges in areas such as type safety, runtime memory management, and type mapping with the host runtime environment. The industry is demanding higher execution efficiency and lower runtime memory overhead while maintaining script usability. Summary of the Invention

[0003] In a first aspect, a method for compiling a script is provided. The method includes: acquiring a first script file and environment definition information, the environment definition information indicating the interaction specifications between the first script file and a host runtime environment; determining, based on the environment definition information and the first script file, the runtime data required to execute the first script file and the storage requirements of the runtime data; determining, based on the storage requirements, a first storage location of the runtime data in a predetermined data space to obtain the memory layout of the first script file; and generating a first image file based on the memory layout, the first image file carrying layout description information for determining the predetermined data space and configured to access the runtime data according to the first storage location during execution, wherein the memory layout remains unchanged during the execution of the first image file.

[0004] In a second aspect, an apparatus for script compilation is provided. The apparatus includes: an acquisition module configured to acquire a first script file and environment definition information, the environment definition information indicating the interaction specifications between the first script file and a host runtime environment; a first determination module configured to determine, based on the environment definition information and the first script file, runtime data required for executing the first script file and storage requirements for the runtime data; a second determination module configured to determine, based on the storage requirements, a first storage location of the runtime data in a predetermined data space to obtain a memory layout of the first script file; and a generation module configured to generate a first image file based on the memory layout, the first image file carrying layout description information for determining the predetermined data space, and configured to access the runtime data according to the first storage location during execution, wherein the memory layout remains unchanged during the execution of the first image file.

[0005] In a third aspect, an electronic device is provided. The device includes at least one processor; and at least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor. When executed by the at least one processor, the instructions cause the device to perform the method of the first aspect.

[0006] In a fourth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores computer-executable instructions that can be executed by a processor to implement the method of the first aspect.

[0007] In a fifth aspect, a computer program product is provided, which is tangibly stored in a computer storage medium and includes computer-executable instructions that, when executed by a device, cause the device to perform the method of the first aspect.

[0008] It should be understood that the content described in this section is not intended to limit the key or important features of the examples in this article, nor is it intended to restrict the scope of the solution. Other features will become readily apparent from the following description. Attached Figure Description

[0009] The above and other features, advantages, and aspects of the various examples herein will become more apparent when taken in conjunction with the accompanying drawings and the following detailed description. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein: Figure 1 A schematic diagram of the example environment is shown; Figure 2 The flowcharts show some scenarios for methods used in script compilation; Figure 3 The diagram illustrates the triggering relationships of script scheduling in some scenarios; Figure 4 The diagram illustrates compiler processing architectures for several scenarios; Figure 5 The diagram illustrates fixed-memory layouts at compile time in several scenarios. Figure 6 The diagram illustrates the first image file structure and loading process in several scenarios; Figure 7 The diagram illustrates the execution instance state machine and host interface access for some scenarios. Figure 8 The diagram illustrates the saving and restoring of execution state in several scenarios. Figure 9 The diagram illustrates several scenarios of aggregated image construction and multi-script scheduling. Figure 10 Block diagrams of apparatuses for script compilation in several scenarios are shown; and Figure 11 A block diagram of an electronic device capable of implementing multiple illustrative scenarios is shown. Detailed Implementation

[0010] The examples in the text will now be described in more detail with reference to the accompanying drawings. While some examples are shown in the drawings, it should be understood that solutions can be implemented in various forms and should not be construed as limited to the examples presented herein. Rather, these examples are provided to provide a more thorough and complete understanding of the solutions. It should be understood that the drawings and examples in this document are for illustrative purposes only and are not intended to limit the scope of protection of the solutions.

[0011] It should be noted that the headings of any section / subsection provided herein are not restrictive. Various examples are described throughout this document, and examples of any type may be included under any section / subsection. Furthermore, examples described in any section / subsection may be combined in any way with any other examples described in the same section / subsection and / or different sections / subsections.

[0012] In the description of the examples in this document, the term "including" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an example" or "the example" should be understood as "at least one example". The term "some examples" should be understood as "at least some examples". Other explicit and implicit definitions may also be included below. The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0013] The examples in this document may involve user data, data acquisition, and / or use. All of these aspects comply with relevant laws, regulations, and rules. In the examples, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, when implementing each example, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained through appropriate means, in accordance with relevant laws and regulations. The specific methods of notification and / or authorization can vary depending on the actual situation and application scenario; the scope of the solution is not limited in this regard.

[0014] In this manual and the sample solutions, any processing of personal information will be conducted only under legal grounds (such as obtaining the consent of the data subject or being necessary for the performance of a contract) and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.

[0015] The term "script file" as used in this article refers to a source file containing program logic written in a scripting language, which may include, but is not limited to, procedural logic descriptions, variable declarations, control flow statements, and interface call statements.

[0016] The term "environment definition information" as used in this document refers to configuration information that describes the interaction specifications between a script file and its host runtime environment. This information may include, but is not limited to, structure definitions, enumeration definitions, and interface definitions. Environment definition information is used to constrain the data types that can be used and the host interfaces that can be called within the script file.

[0017] The term "runtime data" as used in this article refers to all data items required to execute a script file, which may include, but is not limited to, data corresponding to variables declared by the user in the script, intermediate data during expression evaluation, control data used for control flow execution, and literal data in the script.

[0018] As used in this article, the term "pre-allocated data space" refers to a fixed-layout storage area pre-allocated in an execution instance for storing script execution data. The pre-allocated data space may include multiple data segments corresponding to different data types, and no additional script data slots are added during execution.

[0019] The term "memory layout" as used in this article refers to the correspondence between runtime data items determined at compile time and their storage locations within a predetermined data space, including data segmentation, intra-segment location identifiers, and space sizes. The memory layout remains unchanged during the execution of the image file.

[0020] As used in this article, the term "image file" refers to the compiled binary file that carries layout description information and instruction sequences. Image files can be loaded into an execution instance, which then accesses runtime data from a fixed storage location.

[0021] The term "execution instance" as used in this article refers to a runtime entity created after loading an image file, responsible for executing the instruction sequence in the image file line by line and maintaining runtime data in a predefined data space. Execution instances can be in states such as initial, running, suspended, stopped, or abnormal.

[0022] The term "host runtime environment" as used in this article refers to the external runtime environment that hosts script execution, which may include, but is not limited to, game engine runtime, application framework, or other runtime environments that provide interface call capabilities.

[0023] The term "host interface" as used in this article refers to a functional interface provided by the host runtime environment that can be called by script files. The input and output specifications of the host interface are described by the interface definition information in the environment definition information.

[0024] The term "scheduling description information" as used in this article refers to configuration information that describes the correspondence between multiple image files and triggering conditions. Triggering conditions may include time-triggered conditions and event-triggered conditions.

[0025] The term "intermediate representation" as used in this article refers to the program representation generated during the compilation process that lies between the abstract syntax tree and the final bytecode, including data segment descriptions corresponding to runtime data and intermediate instruction sequences corresponding to script operations.

[0026] The term "target precision mode" as used in this article refers to the precision configuration used for storing and operating numerical data, which may include, but is not limited to, single-precision floating-point mode, double-precision floating-point mode, and fixed-point mode. The target precision mode remains unchanged during the determination of the memory layout, affecting the representation width and computational behavior of numerical data.

[0027] As mentioned above, scripting is a widely adopted technique in game logic development. In traditional solutions, virtual machines running general-purpose scripting languages ​​often dynamically allocate memory during execution, such as creating table objects, performing string concatenation, or capturing closure variables. These dynamic memory allocation operations can lead to memory fragmentation and pauses caused by garbage collection (GC), which is detrimental to real-time applications requiring high frame rate stability. Furthermore, type mapping between general-purpose scripting languages ​​and host languages ​​typically requires manually written binding code, resulting in high maintenance costs and potential inconsistencies. While the rich functionality of general-purpose scripting languages ​​provides flexible expressive power, it also increases the risk of script complexity creep, making it difficult to effectively guarantee script security and predictability.

[0028] A script compilation scheme is proposed. The scheme includes: acquiring a first script file and environment definition information, wherein the environment definition information indicates the interaction specifications between the first script file and the host runtime environment; determining the runtime data required to execute the first script file and the storage requirements of the runtime data based on the environment definition information and the first script file; determining a first storage location of the runtime data in a predetermined data space based on the storage requirements to obtain the memory layout of the first script file; and generating a first image file based on the memory layout, the first image file carrying layout description information for determining the predetermined data space and configured to access the runtime data according to the first storage location during execution, wherein the memory layout remains unchanged during the execution of the first image file.

[0029] The above approach identifies and plans the storage locations of all script runtime data during compilation, enabling the generated image file to access runtime data in fixed storage locations determined during compilation, without dynamically allocating new script data slots during execution. Consequently, the memory usage of the execution instance can be determined during image loading, eliminating the need for garbage collection to reclaim script data storage space, thus reducing computational overhead and latency jitter caused by dynamic memory allocation and garbage collection. Simultaneously, due to the fixed and contiguous memory layout, the cache hit rate of the Central Processing Unit (CPU) is improved, resulting in increased instruction execution efficiency.

[0030] The following describes various examples of this scheme in further detail with reference to the accompanying drawings.

[0031] Example Environment Figure 1 A schematic diagram of example environment 100 is shown. (e.g.) Figure 1 As shown, the example environment 100 may include a development device 110 and a compilation device 120. A script editing application 112 may run in the development device 110 to edit a first script file 114 and environment definition information 116.

[0032] The compilation device 120 may include a script compiler 122 and an image building module 124. The script compiler 122 receives a first script file 114 and environment definition information 116, analyzes the first script file 114, determines the runtime data required to execute the first script file 114 and the storage requirements of the runtime data, determines the storage location of the runtime data in a predetermined data space to obtain a memory layout, and generates an instruction sequence based on the memory layout. The image building module 124 generates a first image file based on the memory layout and instruction sequence, and can store the first image file in an image file storage 126.

[0033] The first image file can be transmitted to the game application / host runtime environment 142 via a transmission medium or communication network 130. The game application / host runtime environment 142 may include a logic scheduling module 144, an execution instance / virtual machine 146, a reserved data space 148, a host interface 150, and a game state and event source 152.

[0034] The logic scheduling module 144 is used to establish or wake up the execution instance 146 according to time-triggered or event-triggered conditions. After loading the first image file, the execution instance 146 establishes a predetermined data space 148 according to the memory layout determined at compile time, and executes the instruction sequence in the first image file one by one. The execution instance 146 interacts with the game state and event source 152 through the host interface 150 to obtain game state information or respond to game events.

[0035] The development device 110 and the compilation device 120 can be any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, handheld computers, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some cases, the development device 110 and the compilation device 120 can be the same device.

[0036] The game application / host runtime environment 142 can run on the game client on the player's terminal or on the game server. The transmission medium or communication network 130 can include, but is not limited to, local area network connection, mobile network connection, Universal Serial Bus (USB) connection, Wireless Fidelity (WiFi) connection, etc., and is not limited in this respect.

[0037] It should be understood that the structure and function of the various elements in environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of the scheme.

[0038] The following description of the example will continue with reference to the accompanying drawings.

[0039] Example process Figure 2 Example process 200 for script compilation is shown under several scenarios. Process 200 can be executed by compilation device 120. Boxes 210 to 240 illustrate the main flow from acquiring compilation input, identifying all runtime data, planning fixed memory layout, to generating the first image file. In some cases, this main flow can also be combined with compile-time verification, intermediate representation and optimization, image loading and execution, suspension and resumption, host interface access, state saving and restoration, and multi-script aggregation scheduling. Process 200 is described below according to the order of data flow in each processing stage.

[0040] In box 210, the compilation device 120 acquires the first script file 114 and environment definition information 116. The first script file 114 describes a piece of processing logic to be executed, and its content may include user variable declarations, literals, expressions, control flow such as conditions or loops, host interface calls, and waiting operations. Taking game logic as an example, the first script file 114 may describe operations such as playing background music, displaying prompts, waiting for a predetermined time, modifying the area state, or causing the game character to enter a target stage.

[0041] by Figure 3Taking the level startup process as an example, the first script file can be level_boot.gp, which describes, according to script syntax, playing background music, displaying the first prompt, waiting for 2 seconds, and displaying the second prompt; the first script file can also be on_enter_boss_room.gp or on_boss_enrage.gp, used to set the area state when the player enters a specific area of ​​the virtual scene, or to switch the boss from the first phase to the second phase when the boss's health first drops below 30%. Each script file describes a relatively independent piece of game processing logic and is input into the script compiler 122 as an independent compilation unit.

[0042] Environment definition information 116 indicates the interaction specifications between the script file and the host runtime environment 142. For example, environment definition information 116 is used to limit the host data types and host interfaces that the first script file 114 can use. Environment definition information 116 is used to describe the first field layout of a structure in the host runtime environment, which may include at least one of structure definition information, enumeration definition information, and interface definition information. Structure definition information may describe at least one of structure name, field name, field type, field order, field offset, and structure size; enumeration definition information may describe enumeration type and its members; interface definition information is used to describe the host interface that the first script file can call and the input / output specifications of the host interface, which may describe at least one of interface name, input parameters, output parameters, parameter types, and calling conventions. Thus, the script compiler 122 can learn the correspondence between script-side symbols and data and functions in the host runtime environment 142.

[0043] As an example, environment definition information may include the structure definition information of a specific area state structure of the virtual scene, the enumeration definition information of the game event enumeration, and the interface definition information of the host interface. The specific area state structure of the virtual scene may include fields such as whether the area has been entered, the target character's stage, and the prompt status; the game event enumeration may include members such as the player entering a specific area of ​​the virtual scene and the target character's health being below a threshold; the host interface may include interfaces such as playing background music, displaying prompts, setting area status, reading character health, and switching character stages. Thus, compiler 122 can determine which data the script can access and with what parameters it can call which game functions when compiling level_boot.gp, on_enter_boss_room.gp, or on_boss_enrage.gp.

[0044] In cases where a structure needs to be directly accessed by the host interface (e.g., when a script needs the host interface to directly access a specific region state structure), the first field layout described in environment definition information 116 is consistent with the second field layout of the corresponding structure in the host runtime environment 142, so that the host interface can access the fields of the structure stored in the predetermined data space based on the second field layout. For example, they can have the same field order, field offset, field width, and alignment. The compilation device 120 determines the storage location for the structure fields accordingly, enabling the host interface 150 to access the corresponding fields in the predetermined data space 148 according to the second field layout without needing to perform field-by-field conversion between the script representation and the host representation. For example, the script side and the host side can use the same field order, field offset, field width, and alignment for "Region Entered," "Target Role Stage," and "Prompt Status." Thus, when on_enter_boss_room.gp sets the "Region Entered" field, the host interface 150 can locate the field according to the second field layout without first copying the entire structure to another buffer and then performing field-by-field conversion.

[0045] In some cases, the compilation device 120 also acquires a numerical precision configuration. This configuration can be provided by the project configuration, build task, compilation command, or target platform configuration of the host runtime environment, without needing to be automatically inferred from the contents of the first script file 114. The numerical precision configuration is used to determine the target precision mode for this compilation from candidate modes such as single-precision floating-point mode, double-precision floating-point mode, and fixed-point mode. The target precision mode is used to store and operate on numerical data in the runtime data. The target precision mode determines the representation width, alignment requirements, and operation rules of the numerical data, and remains unchanged during the determination of the memory layout. For example, if the level only needs to represent prompt parameters, wait time, and health thresholds, the project can choose single-precision floating-point mode for this build; if the same type of script is used for calculations requiring higher numerical precision, double-precision floating-point mode can be selected; if the project requires consistent discrete calculation results on different devices, fixed-point mode can also be selected. The selected target precision mode determines the representation width, alignment requirements, and operation rules of the numerical data, and remains unchanged during the determination of the memory layout.

[0046] In box 220, the compilation device 120 determines the runtime data required to execute the first script file and the storage requirements for that runtime data based on the environment definition information and the first script file. In some cases, the compilation device 120 can obtain a syntax tree by performing lexical and syntactic analysis on the first script file 114. As an example, the compilation device 120 can perform lexical and syntactic analysis on the first script file 114 to identify lexical units such as keywords, identifiers, literals, and operators, and construct a syntax tree according to the syntactic rules of the scripting language. The compilation device 120 can parse the environment definition information 116 to establish a structure type table, an enumeration member table, and a host interface table that can be used for subsequent analysis. Taking level_boot.gp as an example, the compiler can identify the interface name, numeric literal, call parameters, and sequence control relationships from play_bgm(1.0), show_hint(101.0), wait(2.0), and show_hint(102.0), respectively; taking on_boss_enrage.gp as an example, it can identify the sequence relationship between the target role switching stage and the display prompt.

[0047] The compilation device 120 performs semantic analysis on the syntax tree based on the environment definition information 116 to obtain symbolic information. Symbolic information can indicate the type and scope of variables or temporary data, the type of literals, the result type of expressions, the layout of structure fields, the values ​​of enumeration members, the parameters and return values ​​of the host interface, and the definition and usage relationships in the control flow. Based on the syntax tree and symbolic information, the compilation device 120 can determine the data read by each operation, the data generated, and the order in which the data is used in the control flow.

[0048] During the compilation of the first script file (e.g., during semantic analysis), the compilation device 120 can also perform verification on the first script file based on environment definition information (e.g., compile-time verification). This verification may include at least one of type consistency verification, interface call parameter verification, and enumeration member reference verification. For example, the compilation device 120 can check whether the data types on both sides of the assignment are compatible, whether the amount and type of the interface arguments conform to the interface definition, whether the referenced enumeration members exist, and whether the access to structure fields is out of bounds. As an example, for level_boot.gp, the compiler can verify whether the amount and type of the arguments of play_bgm, show_hint, and wait conform to the corresponding interface definition; for on_boss_enrage.gp, the compiler can verify whether the referenced second-stage enumeration members have been declared in the environment definition information; for on_enter_boss_room.gp, the compiler can verify whether the Boss room status field to be written exists and whether the field type is consistent. In response to a verification failure, the compilation device 120 outputs an error message corresponding to the failed item and can stop generating the first image file, thus allowing the corresponding error to be detected before the image is executed.

[0049] After successful verification, the compilation device 120 determines the runtime data required to execute the first script file 114. The runtime data includes not only the data corresponding to user variables in the first script file 114, but also intermediate data such as temporary results generated by expression evaluation, control data used by the control flow during execution such as conditional branch markers, loop counts or iteration positions, program counters, execution states, and wake-up conditions, as well as numeric, Boolean, enumeration, string, or other literal data. Data implicitly generated by the compiler for syntactic structures but not explicitly declared in the script text can also be identified as runtime data. Taking level_boot.gp as an example, the runtime data may include the numerical parameter 1.0 of the background music playback interface, the prompt identifiers corresponding to the first and second prompts, the waiting duration 2.0, the program counter indicating the current execution position, and the wake-up condition used during the waiting period; taking on_enter_boss_room.gp as an example, it may also include references or field data of the specific area state structure, boolean data indicating that the area has been entered, and event handling control data; taking on_boss_enrage.gp as an example, it may also include target character stage enumeration data, intermediate data generated by comparing health thresholds, and parameters of the stage switching interface.

[0050] For each piece of runtime data, the compiler device 120 determines the corresponding storage requirements. Storage requirements may include data type, data width, number of elements, alignment requirements, initial value, data segment, active range, and whether output is needed when saving the execution state. For arrays or structures, storage requirements may also include the number of elements, field layout, or instance size; for reference data, storage requirements may include the space required to store references, handles, or indexes; for numeric data in target precision mode, storage requirements are determined according to the numeric width corresponding to that target precision mode. Taking level_boot.gp as an example, the compiler determines the numeric storage requirements for a 2.0-second wait duration, the numeric or reference storage requirements for the two prompt flags, and the control data storage requirements for the recovery location after the wait instruction; taking a specific region state structure as an example, the compiler determines the storage space required for the structure fields or structure references based on their field types and field layout. These storage requirements serve as input for box 230 in determining the data segment and its location.

[0051] In some cases, the compilation device 120 generates an intermediate representation based on the syntax tree and symbol information. The intermediate representation may include a data segment description corresponding to the runtime data and an intermediate instruction sequence corresponding to the operations in the first script file 114. This intermediate representation can be used to generate the instruction sequence in the first image file. The data segment description records the type, size, and allocation position of data items, while the intermediate instruction sequence represents operations such as assignment, computation, branching, looping, interface calls, waiting, and returning in a form closer to the target bytecode than the script source code. For example, the intermediate representation of level_boot.gp can represent show_hint(101.0) as a display hint operation with a hint identifier position, and wait(2.0) as a suspension operation with a wait duration position and a resume position; the intermediate representation of on_boss_enrage.gp can represent the second-stage enumeration value and the target role stage switching interface as a stage switching operation with the target field position.

[0052] The compilation device 120 can optimize the intermediate representation. Optimization may include at least one of the following: temporary variable elimination, constant folding, copy propagation, dead code elimination, control flow simplification, and memory reuse. For example, expressions that can be evaluated at compile time can be replaced with constants; computations not used by subsequent instructions can be removed; and redundant temporary variables used only for data transfer can be eliminated. The optimized intermediate representation is used for subsequent runtime data statistics, memory planning, and instruction generation.

[0053] In box 230, the compilation device 120 determines the first storage location of the runtime data in the predetermined data space based on storage requirements, thereby obtaining the memory layout of the first script file. The predetermined data space 148 can be divided into multiple data segments according to data type, such as at least two of the following: numeric segment, boolean segment, enumeration segment, first reference segment, second reference segment, and third reference segment. The first reference segment is used to store structure references, the second reference segment is used to store array references, and the third reference segment is used to store string references. In some implementations, boolean data and enumeration data can reside in the same physical segment, and different reference types can also reside in a unified reference segment, as long as the layout description information can distinguish the corresponding data items.

[0054] In some cases, the compilation device 120 can allocate each piece of data in the runtime data to a data segment corresponding to its data type. After determining the data segment, the compilation device 120 determines an intra-segment location identifier for each piece of runtime data. The first storage location can be determined jointly by the data segment identifier and the intra-segment location identifier, and may further include byte offsets, slot numbers, or element indexes. For structure data, the first storage location can also be determined by combining field offsets to determine the location of specific fields. Based on this, the compilation device 120 calculates the number, size, and starting offset of each data segment to obtain the memory layout of the first script file 114.

[0055] To reduce the size of the predetermined data space 148, the compilation device 120 can determine a first active range for a first data item and a second active range for a second data item in the runtime data. In response to the first and second active ranges not overlapping, the two data items belonging to the same data segment and having the same storage space size, the compilation device 120 allocates the two data items to the same storage location. For example, if the temporary result of the first expression is no longer available after the last read, while the temporary result of the second expression is generated subsequently, they can reuse the same numerical slot.

[0056] The memory layout obtained through the above processing defines the correspondence between runtime data items and storage locations. The so-called memory layout remaining unchanged during the execution of the first image file means that the predetermined data segment size is not changed during execution, no new script data slots are added, and instructions access the corresponding runtime data according to the location determined at compile time; this does not exclude the host runtime environment 142 from performing memory management for graphics, network, or other non-script business purposes.

[0057] In box 240, compilation device 120 generates a first image file based on an intermediate representation and memory layout. The first image file carries layout description information for determining the predetermined data space and is configured to access the runtime data according to the first storage location during execution, wherein the memory layout remains unchanged during the execution of the first image file.

[0058] As an example, the first image file may include an image header, initial data space content, layout description, code segments, and optional string segments. The layout description information may indicate at least one of the following: the number, size, starting offset, intra-segment position identifier of each data segment, and initial value; the instruction sequence in the code segment reads or writes runtime data through the corresponding position identifiers. Since the location of all script runtime data is already determined, the instruction sequence does not need to include runtime memory allocation instructions for expanding the predetermined data space or adding script data slots.

[0059] When the first image file is loaded, execution instance 146 establishes a predetermined data space 148 based on the layout description information, writes initial values ​​to the corresponding positions, and begins execution from the entry position of the instruction sequence. During execution, arithmetic instructions, control flow instructions, interface call instructions, and wait instructions all access the corresponding runtime data according to the data segment identifier and the position identifier within the segment. Different execution instances can establish their own predetermined data spaces 148 based on the same first image file, thereby maintaining the independent runtime states of each instance.

[0060] When the instruction sequence includes a suspend instruction, execution instance 146 records the wake-up condition and the execution progress to be resumed after executing the suspend instruction, and enters the suspended state from the running state. The wake-up condition can be a target time, waiting duration, target frame number, or target event. The logic scheduling module 144 determines whether the wake-up condition is met when the clock advances or the event arrives, and if it is met, allows execution instance 146 to continue execution from the suspended position without expanding the waiting process into multiple host-side timers.

[0061] When the instruction sequence includes an interface call instruction, this instruction can pass the address of the second storage location associated with the third data item to the target interface in the host runtime environment 142 via a register. The second storage location can be a specific location within the first storage location, or it can be a location determined based on the first storage location and the structure field offset. The target interface directly reads or modifies the third data item according to this address. If the first field layout on the script side is consistent with the second field layout on the host side, the target interface can also access the data according to the field rules of the host structure, thereby reducing the conversion and copying between script data and host data.

[0062] When it is necessary to save the execution state, execution instance 146 can, based on the layout description information, output the running data in the predetermined data space 148 and the execution progress information of the first image file as continuous byte-based status data according to the predetermined data segment order and the determined size of each data segment. The execution progress information may include at least one of the following: program counter, execution state, location of instruction to be restored, and wake-up condition. During restoration, the deserialization process writes each byte back to its corresponding position according to the same layout description and restores the execution progress, allowing the new or rebuilt execution instance to continue execution from the saved location.

[0063] In some cases, the compilation device 120 can obtain multiple image files and scheduling description information corresponding to multiple script files, the multiple script files including the first script file, the scheduling description information being used to describe the correspondence between the multiple image files and triggering conditions, the triggering conditions including at least one of time-triggered conditions and event-triggered conditions; and based on the multiple image files and the scheduling description information, generate a second image file, the second image file being configured to cause the image file corresponding to the triggering condition to be executed when the triggering condition is met.

[0064] When multiple processing steps need to be orchestrated, the compilation device 120 or the image building module 124 can also obtain multiple image files corresponding to multiple script files, as well as scheduling description information. The scheduling description information describes the correspondence between time-triggered conditions or event-triggered conditions and the corresponding image files. The image building module 124 generates a second image file based on the multiple image files and scheduling description information. The second image file is used to organize multiple process images and their triggering relationships; at runtime, when the triggering conditions are met, the corresponding process image is selected and an execution instance is established or awakened.

[0065] thus, Figure 2 The process described does not merely translate script text into bytecode; rather, it completes runtime data identification, storage requirement calculation, and fixed-location allocation during compilation, ensuring that the generated first image file carries information capable of reconstructing this fixed layout. Compile-time verification reduces the likelihood of type or interface errors entering runtime, location reuse reduces the size of the predetermined data space, fixed layout makes memory usage predictable, and provides a common data foundation for suspension and resumption, direct access to the host interface, continuous byte state preservation, and unified scheduling of multiple scripts.

[0066] Figure 3 This illustrates script scheduling trigger relationships based on certain scenarios. The following example uses a prelude level of a virtual scene to illustrate this. Figure 2 The compilation process shown is in Figures 3 to 9The specific implementation of the level is as follows. The overall gameplay of the level is broken down into relatively independent processes such as level start, wave hints, specific area readiness, player entry into specific areas, and target character low health enrage. Each process is described by a script file and compiled into a process image.

[0067] In this example, host developers can pre-declare specific area state structures, game event enumerations, and host interfaces using environment definition information. For example, a specific area state structure might include fields such as whether the area has been entered, the target character's current stage, and a prompt status; a game event enumeration might include members such as the player entering a specific area of ​​the virtual scene and the target character's health first falling below a threshold; and a host interface might include interfaces for playing background music, displaying prompts, setting area states, and switching target character stages. The names and fields mentioned above are for illustrative purposes only; actual projects can provide other structures, enumerations, and interfaces based on the host runtime environment 142.

[0068] The scheduling description information 316 associates the triggering conditions with the process image. In box 302, when the level's cumulative time is 0 seconds, the time trigger item triggers level_boot.gpc, compiled from level_boot.gp; this process sequentially calls the background music playback interface, displays the first prompt, performs a 2-second wait operation, and displays the second prompt. In box 304, when 5 seconds have elapsed, the time trigger item triggers wave_hint.gpc; in box 306, when 12 seconds have elapsed, the time trigger item triggers boss_door_ready.gp. Therefore, the level's fixed beats do not need to be centrally written in a continuously running giant script.

[0069] In box 308, when the game state and event source 152 detect that a player has entered a specific area of ​​the virtual scene, a game event corresponding to the event condition is generated. In box 310, the logic scheduling module 144 triggers the processing logic represented by on_enter_boss_room.gpc accordingly to set the area state and display a third prompt. In boxes 312 and 314, when the target character's health first falls below 30%, a game event corresponding to the event condition is generated, triggering the processing logic represented by on_boss_enrage.gp to cause the target character to enter the second phase and display a fourth prompt. Whether the event is "first time" can be guaranteed by the host event source, scheduling state, or a boolean flag in the script execution data.

[0070] The scheduling description information 316 can take the form of a table or other structured data, recording the trigger type, trigger parameters, event member identifier, and target image identifier. For example, the time trigger row records the mapping between 0 seconds, 5 seconds, and 12 seconds and the corresponding process image, while the event trigger row records the mapping between events such as entering a specific area of ​​the virtual scene and the Boss's low health event and the corresponding process image. This table describes the trigger orchestration between multiple processes, while each process image describes a relatively independent processing logic.

[0071] Figure 4 The compiler processing architecture for a single procedural script in the above example is illustrated. Taking level_boot.gp as the first script file 402 as an example, the environment definition information 404 provides the parameter specifications for the background music playback interface and the prompt display interface, and the numerical precision configuration 406 provides the target precision mode used in this build. The definition information parsing phase 408 converts the host structure, enumeration, and interface description into the compiler's internal type and symbol definitions.

[0072] In the lexical / syntax analysis phase 410, the compiler constructs a syntax tree from the interface calls, literals, and wait statements in level_boot.gp. In the semantic analysis and verification phase 412, the compiler parses each interface identifier, verifies the data types of arguments such as background music identifiers, prompt identifiers, and wait durations, and checks the validity of enumeration members or structure fields. For example, if the prompt interface requires a numeric prompt identifier but the script passes an undefined structure, or if the script references an undeclared interface, the corresponding error message is output and the image generation is terminated.

[0073] After successful verification, the intermediate instruction generation stage 414 can generate an intermediate instruction sequence representing "call the background music playback interface", "call the first prompt display interface", "wait 2 seconds", "call the second prompt display interface", and "return", and simultaneously generate corresponding data segment descriptions. The optimization processing stage 416 can fold constant expressions, delete unused temporary calculations, simplify the sequential control flow, and merge reusable temporary slots according to the active range.

[0074] In the data identification and storage planning phase 418, all data required for the process to be executed is collected, and the numerical width and the size of each data segment are determined according to the target precision mode. In the code generation phase 420, intermediate instructions are converted into bytecode that accesses data via location identifiers, ultimately resulting in the memory layout 422 and the first image file 424. The target precision mode does not switch during the layout determination process; therefore, numerical segments within the same process image have a defined data representation.

[0075] Figure 5An example of a compile-time fixed memory layout for example script 510 (e.g., level_boot.gp) is shown. Compile-time identified runtime data 520 may include literal data such as background music flags, first prompt flags, wait durations, and second prompt flags, as well as intermediate data generated by API calls, user variables explicitly declared in the script, and control data such as the program counter, execution status, and wake-up conditions. Figure 5 The values ​​N0=1.0, N1=101.0, N2=2.0, and N3=102.0 shown in the example can be stored in the numerical field as interface parameters or waiting parameters, respectively; the specific business meaning of each value is determined by the definition of the corresponding host interface.

[0076] The target precision mode 530 determines the storage width for N0 to N3 and other numerical data. If the project uses single-precision floating-point mode, each numerical slot can be set according to single-precision format; if double-precision floating-point mode is used, it is set according to double-precision format; if fixed-point mode is used, it is set according to the predetermined number of integer and decimal places. The compiler calculates the storage requirements 540 based on the selected mode, and the selected mode remains unchanged during the determination of the fixed memory layout 550.

[0077] The predefined data space 560 may include a running state segment, a numeric segment, a Boolean or enumeration segment, a reference segment, and an optional structure or array instance segment. The running state segment stores the program counter, current state, and wake-up condition; the numeric segment stores values ​​from N0 to N4; the Boolean or enumeration segment can store flags such as "has berserk mode been triggered" and target character phase enumeration values; the reference segment can store references to specific region state structures, arrays, or strings. The size of each data segment and the position of each data item within a segment are determined before the image is generated.

[0078] In storage location reuse example 570, temporary data T0 and temporary data T1 correspond to intermediate results of different expressions. If T0 has been used for the last time before T1 is generated, their active ranges do not overlap, and they belong to the same numeric segment and have the same storage space size, then the compiler can allow T0 and T1 to share N4 in the numeric segment. This reuse changes the planning method for using the same reserved location at different times, and will not create or expand the location during execution.

[0079] Once the fixed memory layout 550 is established, the predetermined correspondence between data items and storage locations is maintained during image execution. For example, the wait duration is always read by the wait instruction via N2 or its corresponding location identifier, and the target role stage enumeration value is always written to the pre-allocated enumeration location. Even if the execution instance is suspended and resumed multiple times, the size of the data segment and the existing location identifiers remain unchanged.

[0080] Figure 6The structure of the first image file 600 and its loading process are shown. The image header 610 can record the number, size, and offset of each data segment, the code segment size, and optional string segment information. The initial content or layout description of the data space 620 can record numeric literals, Boolean or enumeration initial values, reference initial values, and the position of each data item. The code segment 630 stores the instruction sequence generated according to level_boot.gpc, and the string segment 640 can store prompt text constants or string information used to locate host resources.

[0081] When loading the image and establishing execution instance 650, execution instance 146 first reads the image header 610 and establishes a predetermined data space 148 according to the segment size in it; then, it writes the initial content of the data space into the corresponding segment position and sets the program counter to the entry point of code segment 630. This loading process can occur when the process is first triggered, or it can be completed in advance during the level loading phase.

[0082] Taking level_boot.gp as an example, the first interface call instruction in code segment 630 can read the interface parameters for background music or the first prompt from N0 and other predetermined locations as needed; the wait instruction reads the 2-second wait duration represented by N2; subsequent interface call instructions read the second prompt parameters from locations such as N3; and the return instruction puts the process into a stopped state. The instructions access the location identifiers allocated at compile time, rather than temporarily creating variable storage when the corresponding statement is executed.

[0083] Therefore, no script data slots are added during execution of the instance. For data such as strings, arrays, or structures, the image can reserve reference slots and necessary instance space, or store stable handles managed by the host runtime environment; the specific representation used is determined by the environment definition information and layout description information, but instructions in the code segment still access the corresponding representation according to the predetermined location.

[0084] Figure 7 This illustrates an example of the execution instance state machine 700 and direct access to script data via the host interface. After instance creation, it is in the initial state 710. Upon receiving a start command, it enters the running state 720 and executes code segments 630 line by line. When a return command is encountered, it enters the stopped state 730; if a runtime error occurs preventing further execution, it enters the exception state 750.

[0085] When level_boot.gpc executes a suspend instruction that waits for 2 seconds, the execution instance advances the current program counter to the resume position after the wait instruction, writes the target wake-up time, remaining wait time, or equivalent wake-up conditions to a predetermined position, and enters the suspend state 740 from the running state 720. If a subsequent tick or event check finds that the wake-up condition is met, the execution instance returns to the running state 720 and executes the interface call displaying the second prompt from the resume position.

[0086] In example 760, where the host interface directly accesses script data, the interface call instruction 762 writes the address of the second storage location of the target data to register 764. The host interface 766 retrieves this address from register 764 and accesses the corresponding data. For example, when a player enters a specific area of ​​a virtual scene, on_enter_boss_room.gpc can pass the position of the "Area Entered" field in the specific area status data to the area status setting interface, and the host interface directly updates this field to true. When the target character's health first drops below 30%, on_boss_enrage.gpc passes the address of the target character's stage field and the second stage enumeration value to the stage switching interface, and the host interface directly updates this field and causes the target character to enter the second stage.

[0087] The script-defined data space 770 stores a specific region state structure according to the first field layout in the environment definition information, and the corresponding structure 780 on the host side has a consistent second field layout. Because the field order, offset, and width are consistent, the host interface 766 can locate the target field (e.g., the "Region Entered" or "Target Role Stage" field) according to the second field layout without having to copy the complete structure to a temporary buffer and then convert it. The address range and data types accessible by the interface can still be constrained by compile-time verification and runtime boundary checks.

[0088] Similarly, the interface call instructions in on_boss_enrage.gpc can pass the address of the target role's phase enumeration or a specific region's state structure field to the target interface, causing the target interface to change the target role's phase to the second phase. If the interface returns a result, that result is also written to the location reserved for return data at compile time. Thus, the input and output between the script and the host interface all fall within the locations that can be determined by the layout description.

[0089] Figure 8 The saving and restoring of the execution state is illustrated. When level_boot.gpc is in a suspended state waiting for 2 seconds, the execution instance 810 at the time of saving may include interface parameters and wait parameters in the numeric segment, gate state in the boolean or enumeration segment, stable reference representation in the reference segment, and program counter, suspended state, and wake-up condition in the running state segment.

[0090] The serialization module 820 reads the running status segment, value segment, boolean or enumeration segment, reference segment, and other data segments that need to be saved in a predetermined order according to the layout description information of the first image file 600, and combines them with the execution progress information into status data 830 in the form of consecutive bytes. For native addresses that cannot be directly reused across execution environments, the reference data can be saved as object identifiers, resource identifiers, or reconstructable handles, instead of directly saving the process address.

[0091] During recovery, the deserialization module 840 verifies whether the state data 830 matches the corresponding image layout, and writes each byte into the predetermined position of the recovered execution instance 850 according to the same data segment order. Simultaneously, it restores the program counter, execution state, and wake-up conditions. If the wake-up time has not yet been reached during saving, the recovered instance remains suspended; if the wake-up conditions are met during recovery, the logic scheduling module 144 can put it into the running state and continue executing the second prompt.

[0092] The aforementioned state data can be used for game saving, reconnecting after disconnection, or synchronizing network status. Since the size and order of each data segment are determined at compile time, the serialization module does not need to traverse an uncertain dynamic object graph to infer the data structure during saving, thus enabling it to output and restore the script execution state according to defined boundaries.

[0093] Figure 9 This illustrates the construction of aggregated images and the scheduling of multiple scripts. During the build phase, multiple process images 910, including level_boot.gpc, wave_hint.gpc, boss_door_ready.gpc, on_enter_boss_room.gpc, and on_boss_enrage.gpc, along with scheduling description information 920, are provided to the logical image construction module 930. Figure 2 The method shown determines the memory layout independently.

[0094] The logical image construction module 930 verifies whether the image referenced in the scheduling description information 920 exists, whether the time parameters are valid, and whether the event members are declared in the environment definition information. It then organizes multiple process images and triggering relationships into a second image file or an aggregate image 940. The second image file 940 is the carrier used to organize multiple process images and scheduling relationships and should not be confused with any of the scheduled target process images 958 or 960.

[0095] In the runtime logic scheduling 950, the time progression information 952 may include the cumulative time since the start of the level or the current logic frame, and the game event information 954 may include events such as the player entering a specific area and the target character having low health. The logic scheduling module 956 searches for the scheduling relationship in the second image file 940, selects the corresponding timeline process image when 0 seconds, 5 seconds, or 12 seconds have arrived, and selects the event process image when the corresponding game event has arrived.

[0096] For the selected target process image 958 or 960, the logic scheduling module 956 creates a new execution instance 970, or wakes up the corresponding instance if there is already a suspended instance in the target process. Each execution instance executes according to the fixed memory layout of its own process image and can be stopped, suspended, saved, or resumed independently. Thus, the triggering relationship of multiple events is uniformly described by the aggregated image, while each process image carries only a relatively independent processing logic, enabling complex levels to be implemented by combining multiple verifiable and memory-predictable processing procedures.

[0097] Example devices and equipment A corresponding apparatus for implementing the above methods or processes is also provided.

[0098] Figure 10 A block diagram of a script compilation apparatus 1000 is shown for some scenarios. Apparatus 1000 can be implemented as or included in compilation device 120. The various modules / components in apparatus 1000 can be implemented by hardware, software, firmware, or any combination thereof.

[0099] like Figure 10 As shown, the device 1000 includes an acquisition module 1010 configured to acquire a first script file and environment definition information, the environment definition information indicating the interaction specifications between the first script file and the host runtime environment; a first determination module 1020 configured to determine, based on the environment definition information and the first script file, the runtime data required to execute the first script file and the storage requirements of the runtime data; a second determination module 1030 configured to determine, based on the storage requirements, a first storage location of the runtime data in a predetermined data space to obtain the memory layout of the first script file; and a generation module 1040 configured to generate a first image file based on the memory layout, the first image file carrying layout description information for determining the predetermined data space, and configured to access the runtime data according to the first storage location during execution, wherein the memory layout remains unchanged during the execution of the first image file.

[0100] In some cases, the environment definition information includes at least one of the following: structure definition information, which describes the layout of the first field of a structure in the host runtime environment; enumeration definition information, which describes the enumeration type and its members in the host runtime environment; and interface definition information, which describes the host interface that the first script file can call and the input / output specifications of the host interface.

[0101] In some cases, the first field layout is consistent with the second field layout of the corresponding structure in the host runtime environment, so that the host interface can access the fields of the structure stored in the predetermined data space based on the second field layout.

[0102] In some cases, runtime data includes at least one of the following: data corresponding to user variables in the first script file; intermediate data during the evaluation of expressions in the first script file; control data used by the control flow in the first script file during execution; and literal data in the first script file.

[0103] In some cases, the predetermined data space includes multiple data segments corresponding to different data types. Determining the first storage location of the running data in the predetermined data space includes: allocating each piece of data to a data segment corresponding to the corresponding data type according to the data type of each piece of data in the running data; and determining the segment position identifier of each piece of data in the corresponding data segment.

[0104] In some cases, multiple data segments include at least two of the following: a numeric segment for storing numeric data; a boolean segment for storing boolean data; an enumeration segment for storing enumeration data; a first reference segment for storing structure references; a second reference segment for storing array references; and a third reference segment for storing string references.

[0105] In some cases, the second determining module 1030 may also be configured to determine a first active range of a first data item and a second active range of a second data item in the running data; and in response to satisfying a preset condition, to allocate the first data item and the second data item to the same storage location in the predetermined data space, wherein the preset condition indicates that the first active range and the second active range do not overlap, and that the first data item and the second data item correspond to the same data segment and have the same storage space size.

[0106] In some cases, the first determining module 1020 may also be configured to perform lexical and syntactic analysis on the first script file to obtain a syntax tree corresponding to the first script file; perform semantic analysis on the syntax tree based on the environment definition information to obtain symbol information; and determine the running data and the storage requirements of the running data based on the syntax tree and the symbol information.

[0107] In some cases, the apparatus 1000 further includes an intermediate representation generation module, configured to generate an intermediate representation corresponding to the first script file based on the syntax tree and the symbol information. The intermediate representation includes a data segment description corresponding to the runtime data and an intermediate instruction sequence corresponding to the operation in the first script file. The intermediate representation is used to generate the instruction sequence in the first image file.

[0108] In some cases, the device 1000 also includes an optimization module configured to perform optimization processing on the intermediate representation, the optimization processing including at least one of the following: temporary variable elimination, constant folding, copy propagation, dead code elimination, control flow simplification, and storage location reuse.

[0109] In some cases, the device 1000 further includes a verification module configured to verify the first script file based on the environment definition information during the compilation of the first script file; and to output error message corresponding to the failed item in response to the verification failing.

[0110] In some cases, validation includes at least one of the following: type consistency validation; interface call parameter validation; enumeration member reference validation.

[0111] In some cases, the instruction sequence in the first image file includes a suspend instruction, which is configured to cause the execution instance executing the first image file to enter a suspended state and record a wake-up condition so that execution of the first image file can be resumed when the wake-up condition is met.

[0112] In some cases, the instruction sequence in the first image file includes an interface call instruction, which is used to pass the address of a second storage location associated with a third data item in the runtime data to a target interface in the host runtime environment via a register, so that the target interface can directly access the third data item in the runtime data according to the address.

[0113] In some cases, the device 1000 further includes an output module configured to, during the execution of the first image file, output the running data in the predetermined data space and the execution progress information of the first image file in the form of consecutive bytes based on the layout description information, so as to obtain status data for restoring the execution state of the first image file.

[0114] In some cases, numerical data in the runtime data is configured to be stored and processed according to a target precision mode, which remains unchanged during the determination of the memory layout.

[0115] In some cases, the target precision mode may include at least one of single-precision floating-point mode, double-precision floating-point mode, and fixed-point mode.

[0116] In some cases, the device 1000 also includes an information acquisition module configured to acquire multiple image files and scheduling description information corresponding to multiple script files, and the generation module 1040 can also be configured to generate a second image file based on the multiple image files and scheduling description information.

[0117] Figure 11 A block diagram of an electronic device 1100 in which one or more examples may be implemented is shown. It should be understood that... Figure 11 The electronic device 1100 shown is merely exemplary and should not be construed as limiting the functionality and scope of the examples described herein. Figure 11 The electronic device 1100 shown can be used to implement the compiler device 120 as discussed above.

[0118] like Figure 11 As shown, electronic device 1100 is in the form of a general-purpose electronic device. Components of electronic device 1100 may include, but are not limited to, one or more processing units or processors 1110, memory 1120, storage device 1130, one or more communication units 1140, one or more input devices 1150, and one or more output devices 1160. Processor 1110 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 1120. In a multiprocessor system, multiple processors execute computer-executable instructions in parallel to improve the parallel processing capability of electronic device 1100.

[0119] Electronic device 1100 typically includes multiple computer storage media. Such media can be any accessible media that is accessible to electronic device 1100, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 1120 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 1130 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data and can be accessed within electronic device 1100.

[0120] Electronic device 1100 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not explicitly stated... Figure 11 As shown, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks can be provided. In these cases, each drive can be connected to a bus (not shown) via one or more data media interfaces. Memory 1120 may include computer program product 1125 having one or more program modules configured to perform various methods or actions of various examples.

[0121] Communication unit 1140 enables communication with other electronic devices via a communication medium. Additionally, the functionality of components of electronic device 1100 can be implemented using a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, electronic device 1100 can operate in a networked environment using logical connections to one or more other servers, networked personal computers, or another network node.

[0122] Input device 1150 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 1160 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 1100 can also communicate with one or more external devices (not shown) via communication unit 1140 as needed. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 1100, or with any device that enables electronic device 1100 to communicate with one or more other electronic devices (e.g., network card, modem, etc.). Such communication can be performed via an input / output (I / O) interface (not shown).

[0123] A computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. A computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above.

[0124] The flowcharts and / or block diagrams of the methods, apparatus, devices, and computer program products referred to herein describe various aspects. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0125] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0126] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0127] The flowcharts and block diagrams in the accompanying figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products under various scenarios. In this respect, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the figures. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0128] Various examples have been described above. The foregoing descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A method for compiling a script, comprising: Obtain a first script file and environment definition information, wherein the environment definition information indicates the interaction specifications between the first script file and the host runtime environment; Based on the environment definition information and the first script file, determine the runtime data required to execute the first script file and the storage requirements of the runtime data; Based on the storage requirements, the first storage location of the running data in the predetermined data space is determined to obtain the memory layout of the first script file; as well as A first image file is generated based on the memory layout. The first image file carries layout description information for determining the predetermined data space and is configured to access the runtime data according to the first storage location during execution, wherein the memory layout remains unchanged during the execution of the first image file.

2. The method according to claim 1, wherein the environment definition information includes at least one of the following: Structure definition information, which describes the first field layout of a structure in the host runtime environment; Enumeration definition information, which describes the enumeration types and their members in the host runtime environment; Interface definition information, which describes the host interface that the first script file can call and the input / output specifications of the host interface.

3. The method according to claim 2, wherein the first field layout is consistent with the second field layout of the corresponding structure in the host runtime environment, so that the host interface accesses the fields of the structure stored in the predetermined data space based on the second field layout.

4. The method according to claim 1, wherein the operating data includes at least one of the following: The data corresponding to the user variables in the first script file; Intermediate data during the expression evaluation process in the first script file; The control data used during the execution of the control flow in the first script file; The literal data in the first script file.

5. The method according to claim 1, wherein the predetermined data space comprises a plurality of data segments corresponding to different data types, and determining the first storage location of the running data in the predetermined data space comprises: Based on the data type of each item in the running data, each item of data is assigned to a data segment corresponding to the corresponding data type; as well as Determine the intra-segment position identifier of each data item in the corresponding data segment.

6. The method of claim 5, wherein the plurality of data segments comprises at least two of the following: Numeric segments used to store numeric data; Boolean segment used to store Boolean type data; An enumeration segment used to store enumeration type data; The first reference segment used to store structure references; The second reference segment is used to store array references; The third reference segment is used to store string references.

7. The method of claim 1, wherein determining the first storage location of the running data in the predetermined data space comprises: Determine the first active range of the first data item and the second active range of the second data item in the running data; as well as In response to the fulfillment of preset conditions, the first data item and the second data item are allocated to the same storage location in the predetermined data space. The preset conditions indicate that the first active range and the second active range do not overlap, and that the first data item and the second data item correspond to the same data segment and have the same storage space size.

8. The method according to claim 1, wherein determining the running data and the storage requirements of the running data includes: Lexical and syntactic analysis are performed on the first script file to obtain a syntax tree corresponding to the first script file; Semantic analysis is performed on the syntax tree based on the environment definition information to obtain symbol information; as well as Based on the syntax tree and the symbol information, the runtime data and its storage requirements are determined.

9. The method according to claim 8, further comprising: Based on the syntax tree and the symbol information, an intermediate representation corresponding to the first script file is generated. The intermediate representation includes a data segment description corresponding to the running data and an intermediate instruction sequence corresponding to the operation in the first script file. The intermediate representation is used to generate the instruction sequence in the first image file.

10. The method of claim 9, further comprising: The intermediate representation is optimized, and the optimization process includes at least one of the following: temporary variable elimination, constant folding, copy propagation, dead code elimination, control flow simplification, and storage location reuse.

11. The method of claim 1, further comprising: During the compilation of the first script file, the first script file is verified based on the environment definition information; as well as In response to the failure of the verification, an error message corresponding to the failed item is output.

12. The method according to claim 11, wherein, The verification includes at least one of the following: Type consistency verification; API call parameter validation; Enumerated member reference verification.

13. The method according to claim 1, wherein the instruction sequence in the first image file includes a suspend instruction, the suspend instruction being configured to cause the execution instance executing the first image file to enter a suspended state and record a wake-up condition, so that execution of the first image file is resumed when the wake-up condition is met.

14. The method of claim 1, wherein the instruction sequence in the first image file includes an interface call instruction, the interface call instruction being used to pass the address of a second storage location associated with a third data item in the runtime data to a target interface in the host runtime environment via a register, so that the target interface directly accesses the third data item in the runtime data according to the address.

15. The method according to claim 1, further comprising: During the execution of the first image file, the running data in the predetermined data space and the execution progress information of the first image file are output in the form of consecutive bytes based on the layout description information, so as to obtain status data for restoring the execution state of the first image file.

16. The method of claim 1, wherein the numerical data in the running data is configured to be stored and processed according to a target precision mode, the target precision mode remaining unchanged during the determination of the memory layout.

17. The method of claim 16, wherein the target accuracy mode comprises at least one of the following: Single-precision floating-point mode; Double-precision floating-point mode; Fixed-point mode.

18. The method of claim 1, further comprising: Obtain multiple image files and scheduling description information corresponding to multiple script files, wherein the multiple script files include the first script file, and the scheduling description information is used to describe the correspondence between the multiple image files and triggering conditions, wherein the triggering conditions include at least one of time-triggered conditions and event-triggered conditions; as well as Based on the multiple image files and the scheduling description information, a second image file is generated. The second image file is configured to execute the image file corresponding to the trigger condition when the trigger condition is met.

19. An apparatus for script compilation, comprising: The acquisition module is configured to acquire a first script file and environment definition information, wherein the environment definition information indicates the interaction specifications between the first script file and the host runtime environment; The first determining module is configured to determine the runtime data required to execute the first script file and the storage requirements of the runtime data based on the environment definition information and the first script file. The second determining module is configured to determine the first storage location of the running data in the predetermined data space based on the storage requirements, so as to obtain the memory layout of the first script file; as well as The generation module is configured to generate a first image file based on the memory layout. The first image file carries layout description information for determining the predetermined data space and is configured to access the running data according to the first storage location during execution, wherein the memory layout remains unchanged during the execution of the first image file.

20. An electronic device, comprising: At least one processor; as well as At least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, the instructions causing the electronic device to perform the method according to any one of claims 1 to 18 when executed by the at least one processor.

21. A computer-readable storage medium having stored thereon computer-executable instructions that can be executed by a processor to implement the method according to any one of claims 1 to 18.

22. A computer program product tangibly stored in a computer storage medium and comprising computer-executable instructions that, when executed by a device, cause the device to perform the method according to any one of claims 1 to 18.

Images