Method, device and terminal for loading memory structure configuration file

Abstract

A method, device, and terminal for loading a memory structure configuration file, the method comprising: converting a memory structure configuration file to be loaded into a source code file, wherein the memory structure configuration file is a multi-field file and the source code file is a single-field file; compiling the source code file to obtain an assembly, wherein the assembly includes multiple member files; determining the offset between the base address of each member file and the base address of the source code file; and loading the memory structure configuration file using the offsets of the various member files. The present invention can implement byte-aligned loading.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and device for loading a memory structure configuration file, and a terminal. Background Art

[0002] In existing non-volatile memory (NV, also known as memory space) data services, memory structure configuration files need to be loaded into the memory space in batches.

[0003] Specifically, during the development process, we typically use configuration files to configure the parameters of certain service applications. The resulting configuration files typically contain information about various hierarchical structures, such as a tree structure. A memory structure configuration file is a memory block structure description file that can be considered a description of files loaded into memory space. Due to limited memory storage space, byte alignment should be achieved as much as possible during the loading process to improve memory space utilization for data access. For example, 4-byte alignment or other byte alignment methods can be used.

[0004] In the prior art, a byte encoding algorithm suitable for memory space (e.g., a 4-byte encoding algorithm) is usually used to calculate the offset of each field of the memory structure configuration file, and then the value of the corresponding field in the memory structure configuration file is filled into the corresponding offset position to realize the loading of the memory structure configuration file.

[0005] However, in the above-mentioned method for loading the memory structure configuration file, the byte encoding algorithm defaults to the memory structure configuration file being based on byte alignment configuration. As a result, when the memory structure configuration file is not a file that has completed the byte alignment operation, or the byte alignment is different from the byte alignment of the memory space, the loaded memory structure configuration file is prone to data access errors due to byte alignment errors.

[0006] There is an urgent need for a method for loading memory structure configuration files that can implement file loading based on byte alignment and improve data access accuracy. Summary of the Invention

[0007] The technical problem solved by the present invention is to provide a method, device and terminal for loading a memory structure configuration file, which can realize loading based on byte alignment.

[0008] To solve the above technical problems, this application provides the following technical solutions:

[0009] In a first aspect, a method for loading a memory structure configuration file is provided, comprising: converting a memory structure configuration file to be loaded into a source code file, wherein the memory structure configuration file is a multi-field file and the source code file is a single-field file; compiling the source code file to obtain an assembly, wherein the assembly includes multiple member files; determining the offset between the base address of each member file and the base address of the source code file; and loading the memory structure configuration file using the offsets of the various member files.

[0010] Optionally, the memory structure configuration file to be loaded can be divided into a plurality of memory structure configuration sub-files corresponding to the member files in the program set according to the memory structure type; the use of the offsets of various member files to load the memory structure configuration file includes: determining the memory structure configuration sub-file corresponding to each member file; using the offsets of various member files as the offsets of the corresponding memory structure configuration sub-files, and loading the corresponding memory structure configuration sub-files into the memory respectively.

[0011] Optionally, the memory structure configuration file is selected from: an extensible markup language XML file, an initialization file INI, and a scripting language object notation JSON file.

[0012] Optionally, the assembly also includes the length of each member file and the order between various member files; the determining of the offset between the base address of each member file and the base address of the source code file includes: determining the difference between the base address of each member file relative to the source code file according to the length and order; and using the difference between the base addresses of each member file as the offset of the member file.

[0013] Optionally, converting the memory structure configuration file to be loaded into a source code file includes: converting the memory structure configuration file into a high-level language source code file; wherein the high-level language source code file is selected from: a C# source code file and a Java source code file.

[0014] Optionally, the C# source code file is a .cs file, and the Java source code file is a .java file.

[0015] Optionally, the method for loading the memory structure configuration file further includes: using a preset byte encoding algorithm to calculate the offset calculation amount of each field in the memory structure configuration file; for the offset calculation amount of each field, comparing the offset between the base address of the various member files and the base address of the source code file with the offset calculation amount of each field; and determining the error rate of the preset byte encoding algorithm based on the comparison result.

[0016] Optionally, the converted source code file is stored in a preset storage list; each time before converting the memory structure configuration file to be loaded into the source code file, the method further includes: clearing the storage list.

[0017] In a second aspect, a device for loading a memory structure configuration file is provided, comprising: a conversion module for converting the memory structure configuration file to be loaded into a source code file, wherein the memory structure configuration file is a multi-field file and the source code file is a single-field file; a compilation module for compiling the source code file to obtain an assembly, wherein the assembly includes multiple member files; an offset determination module for respectively determining the offset between the base address of various member files and the base address of the source code file; and a loading module for loading the memory structure configuration file using the offsets of various member files.

[0018] According to a third aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of configuring the memory structure configuration file are executed.

[0019] In a fourth aspect, a terminal is provided, comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and the processor executes the steps of the above-mentioned method for loading a memory structure configuration file when running the computer program.

[0020] Compared with the prior art, the technical solution of the embodiment of the present invention has the following beneficial effects:

[0021] In an embodiment of the present invention, the memory structure configuration file to be loaded is first converted into a source code file of a single field file, and the member files in the assembly of the source code file are obtained. Then, the memory structure configuration file is loaded using the offset between the base address of each member file and the base address of the source code file. Since the source code file is a single field file, it will naturally have the characteristic of byte alignment during the compilation process. Therefore, the offset is calculated using the member files in the assembly of the source code file, and then the memory structure configuration file is loaded. Regardless of whether the memory structure configuration file to be loaded is based on a byte alignment configuration, byte-aligned loading can be achieved.

[0022] Furthermore, since the memory structure configuration file to be loaded can be divided into a plurality of memory structure configuration sub-files corresponding to the member files in the assembly according to the memory structure type, after determining the memory structure configuration sub-files corresponding to the various member files, the offsets of the various member files can be used as the offsets of the corresponding memory structure configuration sub-files, and the corresponding memory structure configuration sub-files can be loaded into the memory respectively. Since in the process of compiling the coded file to obtain the assembly, a relatively small amount of calculation can often be used to determine or even directly determine the offset between the base address of each member file and the base address of the source code file, compared with the prior art of using a byte encoding algorithm to calculate the offset of each field, the amount of calculation is significantly reduced, which is equivalent to further improving the accuracy of the calculation.

[0023] Furthermore, the program set also includes length information of each member file and order information between various member files, so that the difference between the base address of each member file and the source code file can be determined according to the length and order, and used as the offset of the member file. For example, the lengths of previous member files can be added in order to obtain the difference between the base address of the current member file and the source code file. Compared with the existing technology of using byte encoding algorithm to calculate the offset of each field, the amount of calculation is significantly smaller.

[0024] Furthermore, a preset byte encoding algorithm is used to calculate the offset calculation amount of each field in the memory structure configuration file; for each field's offset calculation amount, the offset between the base address of the various member files and the base address of the source code file is compared with the offset calculation amount of each field; and based on the comparison results, the error rate of the preset byte encoding algorithm is determined. Since the byte encoding algorithm defaults to configuring the memory structure configuration file based on byte alignment, by calculating the error rate, it is possible to reversely infer whether the byte encoding algorithm needs to be improved, and also reversely infer whether there is a situation of byte alignment failure during the configuration of the memory structure configuration file.

[0025] Furthermore, the converted source code files are stored in a preset storage list. Each time before converting a memory structure configuration file to be loaded into a source code file, the method further includes clearing the storage list. This allows the storage list to be cleared in real time, ensuring that only the source code files to be compiled are included in the storage list, reducing interference from historical files and improving compilation accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 is a flow chart of a method for loading a memory structure configuration file according to an embodiment of the present invention;

[0027] Figure 2This is a schematic diagram of a structure tree of an XML file in an embodiment of the present invention;

[0028] Figure 3 is a schematic diagram of a structure tree of an assembly in an embodiment of the present invention;

[0029] Figure 4 yes Figure 1 A flowchart of a specific implementation of step S14;

[0030] Figure 5 This is a partial flow chart of a method for loading a memory structure configuration file according to an embodiment of the present invention;

[0031] Figure 6 It is a structural diagram of a device for loading a memory structure configuration file according to an embodiment of the present invention;

[0032] Figure 7 It is a structural diagram of a terminal in an embodiment of the present application. DETAILED DESCRIPTION

[0033] In the prior art, a byte encoding algorithm suitable for memory space is typically used to calculate the offset of each field in the memory structure configuration file. The offset position is then filled with the value of the corresponding field in the memory structure configuration file to load the memory structure configuration file. However, the loaded memory structure configuration file is prone to data access errors due to byte alignment errors.

[0034] Specifically, taking the memory structure configuration file as "Extensible Markup Language (XML)" as an example, each NV item corresponds to an XML file that can be converted into a structure. When using the NV tool to batch load XML files, all field information in the structure is obtained by parsing the XML, and then the offset of each field in the structure is calculated through the byte encoding algorithm. Finally, the value of the corresponding field in the XML is filled in the corresponding offset to complete the assembly and load the structure into the memory.

[0035] The inventors of the present invention have discovered through research that users often have a wide range of configuration options when configuring memory structure configuration files, such as allowing users to define their own markup language. This can result in some memory structure configuration files not being byte-aligned, or having byte alignments that differ from the byte alignment of the memory space. Therefore, in the prior art, because the byte encoding algorithm defaults to byte-aligned configuration for memory structure configuration files and calculates the offsets of various fields based on this, data access errors can easily occur in the loaded memory structure configuration files due to byte alignment errors.

[0036] The inventors of this invention have also discovered that, theoretically, it might be possible to first convert the memory structure configuration file into a structure header file, then use the structure header file for compilation, instantiate the structure in another process, and assign values ​​to the structure fields one by one using macros, ultimately generating a structure buffer. However, in the prior art, this solution is theoretically unfeasible because software cannot be compiled at runtime.

[0037] In an embodiment of the present invention, the memory structure configuration file to be loaded is first converted into a source code file of a single field file, and the member files in the assembly of the source code file are obtained. Then, the memory structure configuration file is loaded using the offset between the base address of each member file and the base address of the source code file. Since the source code file is a single field file, it will naturally have the characteristic of byte alignment during the compilation process. Therefore, the offset is calculated using the member files in the assembly of the source code file, and then the memory structure configuration file is loaded. Regardless of whether the memory structure configuration file to be loaded is based on a byte alignment configuration, byte-aligned loading can be achieved.

[0038] In order to make the above-mentioned objects, features and beneficial effects of the present invention more obvious and easy to understand, specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0039] Reference Figure 1 , Figure 1 The flowchart of a method for loading a memory structure configuration file according to an embodiment of the present invention is provided. The method can be executed by a terminal, which can be any existing terminal capable of receiving and processing data, such as, but not limited to, a mobile phone, a computer, a tablet computer, a server, a cloud platform, etc. It is understood that in a specific implementation, the method can be implemented as a software program running on a processor integrated within a chip or chip module; alternatively, the method can be implemented using hardware or a combination of hardware and software.

[0040] Figure 1 The method for loading the memory structure configuration file shown may include the following steps:

[0041] S11: Converting the memory structure configuration file to be loaded into a source code file, wherein the memory structure configuration file is a multi-field file and the source code file is a single-field file.

[0042] Among them, in each step number of this application, S means step.

[0043] In a specific implementation of S11, the memory structure configuration file to be loaded may be a loading file that needs to be loaded into the memory space.

[0044] When a user configures a memory structure configuration file, the user may have greater configuration freedom, such as allowing the user to define his or her own markup language.

[0045] Furthermore, the memory structure configuration file may be selected from: an Extensible Markup Language (XML) file, an Initialization File (INI), and a JavaScript Object Notation (JSON) file.

[0046] Specifically, the memory structure configuration file can be any of the following:

[0047] Case 1: The memory structure configuration file can be an XML file.

[0048] XML files, also known as a subset of the Standard Generalized Markup Language (SGML), can be used to tag data, define data types, and serve as the source language for users to define their own markup languages. As a SGML, XML offers advantages such as high scalability, separation of content and form, strict syntax, and good value preservation.

[0049] Specifically, the XML file format is a plain text format consisting of XML elements. Each XML element consists of a start tag ( ), an end tag ( ), and the content between the two tags. For example, an XML element might be tagged as a price, an order number, or a name. Tags describe the document's storage format and logical structure. Formally, tags may include comments, quotes, character data segments, start tags, end tags, empty elements, document type declarations, and preambles.

[0050] Reference Figure 2 , Figure 2 It is a schematic diagram of a structure tree of an XML file in an embodiment of the present invention.

[0051] XML 201 can be used to represent the root element. XML 201 can include multiple XML sub-files. Figure 2 The XML sub-file 211 and the XML sub-file 212 are used for representation, but the present invention is not limited thereto.

[0052] The XML sub-file may include one or more fields of the same memory structure type. Figure 2 The illustrated XML subfile 211 may include 2 fields of type I, and the XML subfile 212 may represent 3 fields of type II.

[0053] The following is an example of an XML file that describes a module named "demo_name" with an ID of 1111.

[0054] The memory structure type may be a structure "STRUCT", the value of type I may be "uint8", and the value of type II may be "uint16".

[0055] The XML subfile 211 of type I may include fields 1 to 2, such as a and b; the XML subfile 212 of type II may include fields 1 to 3, such as c, d, and e.

[0056] <MODULE version="2.0"name="demo_name"core="aa"description="">

[0057] <ITEM name="XXX_NV"id="1111"type="STRUCT"type_name="XXX_NV_T"desc="XXXXX">

[0058] <ITEM name="a"type="uint8"varname="aa"value="0x0"desc="refer toXXXX" / >

[0059] <ITEM name="b"type="uint8"varname="bb"value="0x0"desc="refer toXXXX" / >

[0060] <ITEM name="c"type="uint16"varname="cc"value="0x0"

[0061] desc="XXXX" / >

[0062] <ITEM name="d"type="uint16"varname="dd"value="0x0"desc="refer toXXXX" / >

[0063] <ITEM name="e"type="uint16"varname="ee"value="0x0"desc="refer toXXXX" / >

[0064]

[0065]

[0066] It should be noted that each memory structure configuration file describes an independent memory structure, and a single configuration file can represent a single block of memory space.

[0067] The user can first specify the memory structure type (such as struct, array, union, etc.), and then specify the member variables in the type, such as the fields a and b of UNIT8, the fields c, d, e of UNIT16, etc.

[0068] Case 2: The memory structure configuration file can be INI.

[0069] Specifically, the INI file is used to initialize or set parameters for an operating system or a specific program.

[0070] Similar to XML files, the structure of INI can include: section, key, and comment.

[0071] Among them, sections can be enclosed in square brackets and occupy a separate line, for example: [section].

[0072] A key may also be called a property, and may be used to represent memory structure type information in this application. For example, a key name and a key value may be connected on a separate line using an equal sign, for example: name=value.

[0073] Comments can begin with a semicolon (;) and occupy a separate line. Everything after the semicolon until the end of the line is a comment, for example: ;comment text.

[0074] Case 2: The memory structure configuration file can be a JSON file.

[0075] JSON is a lightweight data exchange format that may be a subset of the JS specification (European Computer Manufacturers Association, ECMAScript) developed by the European Computer Society. It uses a text format that is completely independent of the programming language to store and represent data.

[0076] In JavaScript, objects enclosed in curly braces ({}) are called objects. Their data structure consists of key-value pairs: {key1:value1,key2:value2,...}. In object-oriented languages, keys are object properties, and values ​​are their corresponding values. Keys can be integers or strings, and values ​​can be of any type.

[0077] Among them, key can be used to represent the memory structure type information in this application.

[0078] Continue to refer to Figure 1 In the specific implementation of step S11, the multi-field memory structure configuration file is converted into a source code file. The source code can also be called source code or source program.

[0079] Specifically, the source code file may be a high-level language source code file, for example, any one of the following:

[0080] Case 1: The high-level language source code file can be a C# source code file.

[0081] Furthermore, the C# source code file may be a .cs file, and its suffix may be .cs.

[0082] Case 2: The high-level language source code file may be a Java source code file.

[0083] A Java source code file may refer to an uncompiled text file written in accordance with Java specifications.

[0084] Furthermore, the Java source code file may be a .java file.

[0085] S12: Compile the source code file to obtain an assembly (Assembly), which may include multiple member files.

[0086] In the specific implementation of S12, the assembly can be an intermediate product compiled by a compiler for further compilation and execution. The assembly can include two types of files: an executable file (.exe file) and a class library file (.dll file).

[0087] Reference Figure 3 , Figure 3 It is a schematic diagram of a structure tree of an assembly in an embodiment of the present invention.

[0088] As shown in the figure, the assembly 301 can contain multiple modules. Figure 3 Module 311 and module 312 are used to represent it, but it is not limited to this.

[0089] A single module can contain one or more types. Figure 3 The illustrated module 311 may include type 321 , type 322 , and type 323 .

[0090] A single type can contain one or more member files. Figure 3 The illustrated type 321 may include a method member 331 , a property member 332 , a field member 333 , a double member 334 , an event member 335 , and a constructor member 336 .

[0091] It is understood that member files can be set according to specific circumstances and are not limited to Figure 3 Types shown.

[0092] In the specific implementation, the code will be compiled into an assembly and loaded into memory as an assembly object at runtime.

[0093] Specifically, a module (such as module 311) can be a class (Class) or an interface (Interface), and can be loaded into memory as a type object. Member files (such as method member 331, attribute member 332, field member 333, double member 334, event member 335, and constructor member 336) also have corresponding objects after being loaded into memory.

[0094] It should be pointed out that after the memory structure configuration file is converted into a source code file, the types in the memory structure configuration file are consistent with the member files in the assembly or at least have a one-to-one correspondence.

[0095] Continue to refer to Figure 1 , S13: respectively determine the offset between the base address of each member file and the base address of the source code file.

[0096] During specific implementation of S13, the program set may further include the length of each member file and the order of the various member files.

[0097] According to this order, the base address (also called the starting position or starting address) of the first member file in the assembly can be consistent with the base address of the source code file, or it can differ by a preset interval, and the member files can be arranged continuously, without gaps, and without duplication.

[0098] The offset can be determined in the following two ways:

[0099] Method 1: When compiling the source code file, an appropriate compiler is used, such as a .NET compiler. The compiled assembly will contain the offset of the base address of each member file relative to the base address of the source code file, which can be read directly without calculation.

[0100] Method 2: It can be determined according to the length and order.

[0101] Specifically, the step of determining the offset between the base address of each member file and the base address of the source code file may include: determining the difference between the base address of each member file relative to the source code file according to the length and order; and using the difference between the base addresses of each member file as the offset of the member file.

[0102] More specifically, the lengths of previous member files may be added in order to obtain the difference between the base address of the current member file and the base address of the source code file.

[0103] As a non-limiting example, in conjunction with reference to Figure 2 and Figure 3 , the following example describes a case where two fields of type I in the memory structure configuration file are consistent with method member 331 in the assembly, and three fields of type II in the memory structure configuration file are consistent with method member 331 and attribute member 332 in the assembly. For example, if method member 331 comes first and has a length of L1, and attribute member 332 comes later and has a length of L2, and the base address of method member 331 is consistent with the base address of the source code file or differs by a preset interval D, then the offset of method member 331 is 0 or D, and the offset of attribute member 332 is L2 or D+L2.

[0104] It is understandable that if Figure 2 It also includes type III, type IV, etc., then Figure 3 The corresponding offset of the third member file (length L3) is L2+L3 or D+L2+L3, and the offset of the fourth member file (length L4) is L2+L3+L4 or D+L2+L3+L4...

[0105] It should be pointed out that since the operation method adopted is a continuous addition operation, the complexity and amount of operation for calculating the offset are relatively low.

[0106] In an embodiment of the present invention, the program set also includes length information of each member file and order information between various member files, so that the difference between the base address of each member file and the source code file can be determined according to the length and order, and used as the offset of the member file. For example, the lengths of previous member files can be added in order to obtain the difference between the base address of the current member file and the source code file. Compared with the prior art of using a byte encoding algorithm to calculate the offset of each field, the amount of calculation is significantly smaller.

[0107] S14: Load the memory structure configuration file using the offsets of various member files.

[0108] Reference Figure 4 , Figure 4 yes Figure 1 The step of using the offsets of various member files to load the memory structure configuration file may include steps S41 to S42.

[0109] S41: Determine the memory structure configuration sub-file corresponding to each member file.

[0110] As mentioned above, after the memory structure configuration file is converted into a source code file, the types in the memory structure configuration file are consistent with or at least have a one-to-one correspondence with the member files in the program. The memory structure configuration file to be loaded can be divided into multiple memory structure configuration sub-files corresponding to the member files in the program according to the memory structure type, such as Figure 2 XML subfile 211 and XML subfile 212 are shown.

[0111] S42: Using the offsets of various member files as offsets of corresponding memory structure configuration sub-files, and loading the corresponding memory structure configuration sub-files into the memory respectively.

[0112] In an embodiment of the present invention, since the memory structure configuration file to be loaded can be divided into a plurality of memory structure configuration sub-files corresponding to the member files in the program set according to the memory structure type, after determining the memory structure configuration sub-files corresponding to the various member files, the offsets of the various member files can be used as the offsets of the corresponding memory structure configuration sub-files, and the corresponding memory structure configuration sub-files can be loaded into the memory respectively. Since in the process of compiling the coded file to obtain the program set, a relatively small amount of calculation can often be used to determine or even directly determine the offset between the base address of each member file and the base address of the source code file, compared with the prior art of using a byte encoding algorithm to calculate the offset of each field, the amount of calculation is significantly reduced, which is equivalent to further improving the accuracy of the calculation.

[0113] It should be noted that, in the embodiment of the present invention, the method of using the offsets of various member files to load the memory structure configuration file is not limited to Figure 4 The above-mentioned method shown, for example, can also adopt other appropriate methods. As a non-limiting example, the offset of the member file can be translated (such as adding a fixed value to the offset of each member file), and then the offset after translation can be used to load the memory structure configuration file. The embodiment of the present invention does not limit this.

[0114] In an embodiment of the present invention, the memory structure configuration file to be loaded is first converted into a source code file of a single field file, and the member files in the assembly of the source code file are obtained. Then, the memory structure configuration file is loaded using the offset between the base address of each member file and the base address of the source code file. Since the source code file is a single field file, it will naturally have the characteristic of byte alignment during the compilation process. Therefore, the offset is calculated using the member files in the assembly of the source code file, and then the memory structure configuration file is loaded. Regardless of whether the memory structure configuration file to be loaded is based on a byte alignment configuration, byte-aligned loading can be achieved.

[0115] Reference Figure 5 , Figure 5 This is a partial flow chart of another method for loading a memory structure configuration file in an embodiment of the present invention. The method for loading a memory structure configuration file may include: Figure 1 The steps S11 to S14 shown may further include steps S51 to S53.

[0116] S51: Calculate the offset calculation amount of each field in the memory structure configuration file using a preset byte encoding algorithm.

[0117] The byte encoding algorithm may divide each field and calculate the offset calculation amount of each field, or calculate the offset calculation amount of each group of fields.

[0118] S52: For the calculated offset amount of each field, the offset amount between the base address of each member file and the base address of the source code file is compared with the calculated offset amount of each field.

[0119] It should be pointed out that for different byte encoding algorithms, the division of fields may be consistent with the division of the memory structure configuration sub-files, or may be inconsistent. The field division method is determined by the selected byte encoding algorithm.

[0120] Furthermore, if the division of fields is inconsistent with the division of memory structure configuration sub-files, the offset calculation amount of each field can be first converted into the offset calculation amount of each memory structure configuration sub-file, and then compared with the offset of the corresponding member file to reduce the comparison error.

[0121] S53: Determine the error rate of the preset byte encoding algorithm according to the comparison result.

[0122] Specifically, since the byte encoding algorithm by default forces the structure fields in the memory structure configuration file to be converted to byte alignment first, and then calculates the offset, when the user adds a custom structure, there may be unaligned bytes and incomplete bytes, resulting in miscalculation in the byte encoding algorithm.

[0123] In an embodiment of the present invention, a preset byte encoding algorithm is used to calculate the offset calculation amount of each field in the memory structure configuration file; for each field's offset calculation amount, the offset between the base address of the various member files and the base address of the source code file is compared with the offset calculation amount of each field; and based on the comparison results, the error rate of the preset byte encoding algorithm is determined. Since the byte encoding algorithm defaults to configuring the memory structure configuration file based on byte alignment, by calculating the error rate, it is possible to reversely infer whether the byte encoding algorithm needs to be improved, and also reversely infer whether there is a situation of byte alignment failure during the configuration of the memory structure configuration file.

[0124] Furthermore, the converted source code file may be stored in a preset storage list; each time before converting the memory structure configuration file to be loaded into the source code file, the method may further include: clearing the storage list.

[0125] In an embodiment of the present invention, the converted source code files are stored in a preset storage list. Each time before converting a memory structure configuration file to be loaded into a source code file, the method further includes clearing the storage list. This allows the storage list to be cleared in real time, ensuring that only the source code files to be compiled are included in the storage list, reducing interference from historical files and improving compilation accuracy.

[0126] Reference Figure 6 , Figure 6 1 is a schematic diagram of a device for loading a memory structure configuration file according to an embodiment of the present invention, comprising functional modules for executing the aforementioned method for loading a memory structure configuration file, for example, comprising: a conversion module 61, a compilation module 62, an offset determination module 63, and a loading module 64.

[0127] The conversion module 61 is configured to convert the memory structure configuration file to be loaded into a source code file, wherein the memory structure configuration file is a multi-field file and the source code file is a single-field file.

[0128] The compiling module 62 is used to compile the source code file to obtain an assembly, which includes multiple member files.

[0129] The offset determination module 63 is used to respectively determine the offsets between the base addresses of various member files and the base address of the source code file.

[0130] The loading module 64 is used to load the memory structure configuration file using the offsets of various member files.

[0131] In a specific implementation, the above-mentioned device may correspond to a chip with a data processing function in a terminal; or correspond to a chip module in a terminal including a chip with a data processing function, or correspond to a terminal.

[0132] For more information about the working principle, working method, and beneficial effects of the loading device for the memory structure configuration file in the embodiment of the present application, please refer to the above description of the payment method, which will not be repeated here.

[0133] The embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the method for loading the memory structure configuration file is executed. The computer-readable storage medium may include a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc. The computer-readable storage medium may also include a non-volatile memory or a non-transitory memory, etc.

[0134] Reference Figure 7 , an embodiment of the present application further provides a terminal, including a memory 71 and a processor 72, wherein the processor 72 and the memory 71 are coupled, and the memory 71 can be located inside the terminal or outside the terminal. The memory 71 and the processor 72 can be connected via a communication bus. The memory 71 stores a computer program that can be run on the processor 72, and when the processor 72 runs the computer program, it executes the method for loading the memory structure configuration file provided in the above embodiment. The terminal can be a mobile phone, a computer, a tablet computer, a server, a cloud platform, etc., but is not limited thereto.

[0135] In the embodiment of the present application, the memory 71 includes a non-volatile memory or a non-transitory memory, and may also include an optical disk, a mechanical hard disk, a solid-state hard disk, etc.

[0136] It should be understood that in the embodiment of the present application, the processor 72 may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0137] It should also be understood that the memory 71 in the embodiment of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be RAM, which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM bus random access memory (DRRAM).

[0138] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer program can be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired or wireless means.

[0139] In the several embodiments provided in this application, it should be understood that the disclosed methods, devices and systems can be implemented in other ways. For example, the device embodiments described above are merely schematic; for example, the division of the units is merely a logical function division, and there may be other division methods in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the scheme of this embodiment.

[0140] In addition, the functional units in the various embodiments of the present application may be integrated into one processing unit, or each unit may be physically included separately, or two or more units may be integrated into one unit. The above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units. For example, for various devices and products applied to or integrated into a chip, the various modules / units contained therein may all be implemented in the form of hardware such as circuits, or at least some of the modules / units may be implemented in the form of software programs, which run on the processor integrated inside the chip, and the remaining (if any) modules / units may be implemented in the form of hardware such as circuits; for various devices and products applied to or integrated into a chip module, the various modules / units contained therein may all be implemented in the form of hardware such as circuits, and different modules / units may be located in the same component (such as a chip, circuit module, etc.) or different components of the chip module, or at least some of the modules / units may be located in the same component (such as a chip, circuit module, etc.) or different components of the chip module, or at least some of the modules / units may be located in the same component (such as a chip, circuit module, etc.) or different components of the chip module. The element can be implemented in the form of a software program, which runs on the processor integrated inside the chip module, and the remaining (if any) modules / units can be implemented in the form of hardware such as circuits; for various devices and products applied to or integrated in the terminal, the various modules / units contained therein can be implemented in the form of hardware such as circuits, and different modules / units can be located in the same component (for example, chip, circuit module, etc.) or different components in the terminal, or, at least some modules / units can be implemented in the form of a software program, which runs on the processor integrated inside the terminal, and the remaining (if any) modules / units can be implemented in the form of hardware such as circuits.

[0141] It should be understood that the term "and / or" as used herein simply describes an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " as used herein indicates that the related objects are in an "or" relationship.

[0142] The "multiple" appearing in the embodiments of the present application refers to two or more. The first, second, etc. descriptions appearing in the embodiments of the present application are only for illustration and distinction of the description objects. There is no order, nor does it represent a special limitation on the number of devices in the embodiments of the present application, and cannot constitute any limitation on the embodiments of the present application. Although the present application is disclosed as above, the present application is not limited to this. Any person skilled in the art may make various changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be based on the scope defined by the claims.

[0143] Although the present invention is disclosed as above, the present invention is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention should be based on the scope defined by the claims.

Claims

1. A method for loading a memory structure configuration file, characterized in that: include: Converting the memory structure configuration file to be loaded into a source code file, wherein the memory structure configuration file is a multi-field file and the source code file is a single-field file; Compiling the source code file to obtain an assembly, wherein the assembly includes a plurality of member files; Determine the offset between the base address of each member file and the base address of the source code file respectively; Loading the memory structure configuration file using offsets of various member files; The memory structure configuration file describes an independent memory structure.

2. The method for loading a memory structure configuration file according to claim 1, wherein: The memory structure configuration file to be loaded can be divided into a plurality of memory structure configuration sub-files corresponding to the member files in the program set according to the memory structure type; The use of offsets of various member files to load the memory structure configuration file includes: Determine the memory structure configuration subfile corresponding to each member file; The offsets of various member files are used as the offsets of corresponding memory structure configuration sub-files, and the corresponding memory structure configuration sub-files are loaded into the memory respectively.

3. The method for loading a memory structure configuration file according to claim 2, wherein: The memory structure configuration file is selected from: Extensible Markup Language XML file, initialization file INI, scripting language object notation JSON file.

4. The method for loading a memory structure configuration file according to claim 1, wherein: The assembly also includes the length of each member file and the order between the various member files; Determining the offset between the base address of each member file and the base address of the source file includes: Determine the difference between the base address of each member file and the base address of the source code file according to the length and order; The difference between the base addresses of each member file is used as the offset of the member file.

5. The method for loading a memory structure configuration file according to claim 1, wherein: Converting the memory structure configuration file to be loaded into a source code file includes: Converting the memory structure configuration file into a high-level language source code file; Wherein, the high-level language source code file is selected from: C# source code file and Java source code file.

6. The method for loading a memory structure configuration file according to claim 5, characterized in that: The C# source code file is a .cs file, and the Java source code file is a .java file.

7. The method for loading a memory structure configuration file according to claim 1, wherein: Also includes: Calculating the offset calculation amount of each field in the memory structure configuration file using a preset byte encoding algorithm; For the calculated offset of each field, the offset between the base address of each member file and the base address of the source code file is compared with the calculated offset of each field respectively; According to the comparison result, the error rate of the preset byte encoding algorithm is determined.

8. The method for loading a memory structure configuration file according to claim 1, wherein: The converted source code files are stored in the preset storage list; Each time before converting the memory structure configuration file to be loaded into a source code file, the method further includes: Clear the storage list.

9. A device for loading a memory structure configuration file, characterized in that: include: a conversion module, configured to convert a memory structure configuration file to be loaded into a source code file, wherein the memory structure configuration file is a multi-field file and the source code file is a single-field file; A compiling module, configured to compile the source code file to obtain an assembly, wherein the assembly includes a plurality of member files; An offset determination module, for respectively determining the offset between the base address of various member files and the base address of the source code file; A loading module, configured to load the memory structure configuration file using offsets of various member files; The memory structure configuration file describes an independent memory structure.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of configuring the memory structure configuration file according to any one of claims 1 to 8 are performed.

11. A terminal comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor runs the computer program, the processor executes the steps of the method for loading the memory structure configuration file according to any one of claims 1 to 8.

Images