CN111309449B - Programming language independent virtual machine oriented to meta programming, interactive programming and blockchain interoperation - Google Patents

Abstract

The invention discloses a virtual machine, which analyzes source codes into a structure storage field set representing different parts of a virtual machine program, wherein fields of the structure storage field set represent characteristics of program components, and the structure storage field set comprises one or more of the following components: program root structure, function calls in a call stack, program packages, data structures, functions, expressions, and parameters. The virtual machine has versatility that allows programs written in different programming languages to run on the virtual machine in an interpreted or compiled manner and provides an interface for programmers to different meta-programming and interactive programming tools and processes. Further, virtual machines are designed to be able to split programs, including their program states, for merging with other programs. This functionality may be used in a distributed application program that requires a portion of the running program to be stored on a remote server for later use by other users to create different branches of execution.

Description

Programming language independent virtual machine oriented to meta programming, interactive programming and blockchain interoperation

Technical Field

The invention relates to the technical field of virtual machines, in particular to a programming language independent virtual machine for meta programming, interactive programming and blockchain interoperation.

Background

A Virtual Machine (Virtual Machine) refers to a complete computer system that runs in a completely isolated environment with complete hardware system functionality through software emulation. Work that can be done in a physical computer can be done in a virtual machine. The process virtual machine executes a software application [1] represented by source code written by a user. Hereinafter, the terms "process virtual machine" and "virtual machine" will be used interchangeably.

Common virtual machines are Java virtual machines, linux virtual machines, windows virtual machines, and the like. Different virtual machines may use exactly the same source code and ultimately run programs in different ways, depending on how the virtual machine is implemented and what criteria the designer of the virtual machine decides to follow. For example, there are at least two implementations of the programming language Picolisp, one of which runs on a virtual machine written in assembly language that is suitable for running a 64-bit computer of the Linux distribution, and the other of which runs on a Java virtual machine [2]. Although most programs produce the same results, whatever the virtual machine is used, some differences occur, such as the behavior of the garbage collector. The functionality of the existing virtual machine is poor, and the invention is derived therefrom.

Disclosure of Invention

In order to solve the technical problems, the invention provides a virtual machine which is independent of programming languages and is oriented to meta programming, interactive programming and blockchain interoperation, the virtual machine of the invention considers multifunction in design, allows programs written in different programming languages to run on the virtual machine in an interpretation or compiling mode, and provides interfaces with different meta programming and interactive programming tools and processes for programmers. Further, virtual machines are designed to be able to split programs, including their program states, for merging with other programs. This functionality may be used in a distributed application program that requires a portion of the running program to be stored on a remote server for later use by other users to create different branches of execution.

The technical scheme of the invention is as follows:

a virtual machine that parses source code into a set of structure storage fields representing different portions of a virtual machine program, the fields of the set of structure storage fields representing features of a program component, the set of structure storage fields comprising one or more of: program root structure, function calls in a call stack, program packages, data structures, functions, expressions, and parameters.

In a preferred embodiment, the program root structure stores metadata about a program; the function call in the call stack is distributed on the call stack of the virtual machine, and represents the function call in the program being executed by the virtual machine; the program package is used for packaging or grouping other structures used by the virtual machine, and the name used as the unique identifier of the program package is stored in the program of the virtual machine; the data structure, used by the program, comprises at least a data structure defined by a set of parameters, and a name used as its unique identifier in the package, the data structure storing a reference to the package in which it is packaged; the function, a subroutine in a program running in a virtual machine, has code for identifying whether the function is part of a standard function library of the virtual machine, and the function structure includes: a name serving as a unique identifier in a package containing the function structure, a parameter set serving as a function input, a parameter set serving as a function output, an expression set or a statement set; the expression comprises an input set and an output set to be used by a calling function, a pointer pointing to the function to be executed by using the input and the output, a label uniquely identifying the expression in the function definition, and a pointer pointing to the function and a program package; the parameter represents a pointer to a value constructed from a set of bytes, associated with a type, the parameter comprising the following fields: a field storing a parameter name, a field storing a pointer, a field storing a boolean value, a field storing a boolean flag, a field storing a file name and a file row defining parameters, a field storing an offset, a field storing a set of operations that have to be performed by the virtual machine, a field storing the size of the pointed value, a field storing a set of values, and a field representing different data structures.

The virtual machine provides applications to be fully or partially serialized and de-serialized, allowing the user to extract portions of the program for use in other programs. For example, the program state of one program may be extracted and incorporated into another program. The serialization capability of a virtual machine provides a flexible meta-programming mechanism that allows a program to modify any aspect of itself using a programming paradigm called "availability". For example, if the program state of an application satisfies certain conditions, the program code may change. In addition, the design of virtual machines allows programmers to interact with software development at a deep level of granularity, where the programmers can pause a running program, undo changes made to the program state of the running program, change code, and control how many instructions the virtual machine should execute or return. The above behavior is similar to that of an interpreted programming language, but a virtual machine can interpret or compile its program; in the former case, the user may execute instructions by indicating the program in a read-evaluate-print loop (REPL), or in the latter case, the user may perform a series of optimizations that take the entire program into account before executing the program. Finally, the manner in which the program must be created for the virtual machine should be flexible enough to be programming language independent, meaning that different programming languages can be used to create the structure of the representation program required by the virtual machine, these generated structures can be used by any programming language running on the virtual machine, similar to the manner [3,4] in which Clojure and Scala can run in the same Java runtime environment (Java Runtime Environment).

Compared with the prior art, the invention has the advantages that:

the virtual machine of the present invention allows programs written in different programming languages to run on the virtual machine in an interpreted or compiled manner and provides an interface for programmers to different meta-programming and interactive programming tools and processes. Further, virtual machines are designed to be able to split programs, including their program states, for merging with other programs. This functionality may be used in a distributed application program that requires a portion of the running program to be stored on a remote server for later use by other users to create different branches of execution.

Drawings

The invention is further described below with reference to the accompanying drawings and examples:

FIG. 1 is a schematic diagram of an availability process according to the present invention;

FIG. 2 is a function of a program structure that may occur between two program structures;

FIG. 3 is a function on a program structure that may occur between two program structures;

FIG. 4 is a schematic diagram illustrating a layout of different memory segments of a program to be executed by a virtual machine;

FIG. 5 is a schematic diagram of a program layout after combining blockchain code and transactional code.

Detailed Description

The objects, technical solutions and advantages of the present invention will become more apparent by the following detailed description of the present invention with reference to the accompanying drawings. It should be understood that the description is only illustrative and is not intended to limit the scope of the invention. In addition, in the following description, descriptions of well-known structures and techniques are omitted so as not to unnecessarily obscure the present invention.

Examples:

preferred embodiments of the present invention will be further described with reference to the accompanying drawings.

A virtual machine that parses source code into a set of structure storage fields representing different portions of a virtual machine program, the fields of the set of structure storage fields representing features of a program component, the set of structure storage fields comprising one or more of: program root structure, function calls in a call stack, program packages, data structures, functions, expressions, and parameters. Source code that follows any programming language semantics and syntax can be parsed into these structures.

In order for a virtual machine to accept programs from any programming language (i.e., language independent), the programs must be converted into a set of structures. These structures store a set of fields that represent each feature of the program component. Once the program is converted into a set of structures, the virtual machine can use the structures to run the program in an interpreted manner, and can also sequence the structures into byte arrays that serve as byte codes. The virtual machine has the capability to split and merge a complete program, which allows the creation of a distributed application program, where a portion of the program is stored on a remote server, which a user can query to later merge it into other programs. To understand the use of virtual machines in distributed applications, the structure used to construct the program must be thoroughly described and provide some functionality that is enabled through the use of a process that converts source code into a set of structures.

An efficient program that can run on a virtual machine as proposed in this document must consist of at least one of the following data structures: program, function call, package (program module), data structure, function (subroutine), expression, and parameters. These structures and their fields and types are shown in the following table:

Procedure

field ID	Field name	Type(s)
			1	Path	Character string
2	Program package	[]Program package
			3	Input device	[]Parameters (parameters)
4	Output of	[]Parameters (parameters)
			5	Memory	[]Bytes
6	Stack size	Integer number
			7	Stack size	Integer number
8	Stack start	Integer number
			9	Stack pointer	Integer number
10	Call stack	[]Call I
			11	Call counter	Integer number
12	Heap pointer	Integer number
			13	Has been terminated	Boolean (B)
14	Version of	Character string
			15	Current program package	Program package

Function call

Field ID	Field name	Type(s)
			1	Operator	Function of
2	Row of lines	Integer number
			3	Frame pointer	Integer number

Program package

Data structure

Field ID	Field name	Type(s)
			1	Name of the name	Character string
2	Program package	Program package
			3	Size and dimensions of	Integer number
4	Fields	[]Parameters (parameters)

Function of

Field ID	Field name	Type(s)
			1	Name of the name	Character string
2	Program package	Program package
			3	Is of the original origin	Boolean (B)
4	Function code	Integer number
			5	Input device	[]Parameters (parameters)
6	Output of	[]Parameters (parameters)
			7	Expression type	[]Expression type
8	Length of	Integer number
			9	Size and dimensions of	Integer number
10	File name	Character string
			12	Pointer list	[]Parameters (parameters)
13	Current expression	Expression type

Expression type

Parameters (parameters)

Field ID	Field name	Type(s)
			1	Length of	[]Integer number
2	Dereferencing operations	[]Integer number
			3	Declaration specifier	[]Integer number
4	Index	[]Parameters (parameters)
			5	Fields	[]Parameters (parameters)
6	Name of the name	Character string
			7	File name	Character string
8	Type(s)	Integer number
			9	Size and dimensions of	Integer number
10	Total size of	Integer number
			11	Offset of	Integer number
12	Level of indirection	Integer number
			13	Dereference level	Integer number
14	Delivery of	Integer number
			15	File line	Integer number
16	Custom types	Structure of the
			17	Program package	Program package
18	Is a slice	Boolean (B)
			19	Is an array	Boolean (B)
20	First is an array	Boolean (B)
			21	Is a pointer	Boolean (B)
22	Is a reference to	Boolean (B)
			23	First is de-referencing	Boolean (B)
24	Is a structure	Boolean (B)
			25	Is Rest	Boolean (B)
26	Is a local declaration	Boolean (B)
			27	Is a short statement	Boolean (B)
28	Is an internal reference	Boolean (B)
			29	Previous statement	Boolean (B)
30	Performing escape	Boolean (B)

The procedure is as follows: this structure stores metadata about the program, such as the storage path of the software item, the package or module of the software item, the input and output of the operating system (command line parameters), the start position of the program heap, the heap pointer (to learn where new heap objects can be safely stored), the heap size, the call stack of the program, the size of the stack, the memory of the program (byte array for storing data for use by the virtual machine), the version of the virtual machine, and whether the program is terminated. This is the basic structure for storing all other structures, as explained in more detail below.

Function call: the call represents a function call in a program being executed by the virtual machine. This function call is distributed over the call stack of the virtual machine. The fields required for the structure are a reference to the function to be called, the number of the expression to be called from the function, and a frame pointer indicating the virtual machine on the stack that allocates this function call data.

The program package comprises the following steps: packages (other names of this construct may be modules or namespaces depending on the design of the programming language or implementation thereof) serve as a mechanism for encapsulating or grouping other constructs used by virtual machines, including other packages being imported (packages that will be used by the current package), functions, data structures, and global variables. These structures themselves encapsulate or group other structures, but this will be described in their respective sections. The package structure must also store a name in the program of the virtual machine that serves as its unique identifier.

Data structure: programs use data structures to construct complex data types using the original type and other types defined by other data structures. A data structure defined at least by a set of parameters (see "parameter definition" below, which define a set of types that make up the data structure itself), and a name that is used as its unique identifier in the package. In addition, the data structure stores references to packages that encapsulate it.

Function: a function is a data structure that represents a subroutine in a program running in a virtual machine. The functional structure is defined by the following factors: a name that serves as a unique identifier in a package containing the function structure, a parameter set that serves as a function input (a function in a virtual machine program may receive multiple inputs), a parameter set that serves as a function output (a function in a virtual machine program may return multiple outputs), a set of expressions or statements that are responsible for modifying the state or data of the program by invoking other functions. The function structure also contains metadata: it is a field specifying the number of instructions currently held by the function, the number of bytes required by the function to allocate on the program stack, the file name containing the function definition, the line number from which the function definition starts, the pointer to the package containing the function, the list of parameters contained in the function (input or output of the function itself and input or output of different expressions contained in the function structure), which are considered as pointers to objects on the program stack. In addition to the aforementioned fields, the function structure has code for identifying whether the function is part of a library of virtual machine standard functions (non-user defined functions).

The expression: an expression is a data structure that represents a statement, a function call, or any construct that appears within a function definition. The structure contains input and output sets to be used by the calling function, pointers to functions to be executed using the inputs and outputs, tags uniquely identifying expressions within the function definition, pointers to functions and packages, the pointers containing expressions, filenames and line numbers from which we can find expressions in the source code. In addition to the fields described above, an expression also has a set of fields that describe how the virtual machine needs to interpret the expression: if it is a conditional statement or a loop statement, the expression knows how many expressions need to be skipped or returned in the function definition; if the expression is an expression in a statement block of an if/else statement or a loop statement, the expression stores a number corresponding to the valid range thereof; finally, it stores a set of boolean values that tell the runtime if the expression is a call to a method (a function associated with a particular user-created type), if the expression represents initialization of a structure instance literal, if the expression represents initialization of an array literal, if the output type of the expression is unknown (the virtual machine knows from this information if it needs to perform other procedures at compile time to determine the correct output type), if the expression is a break statement or if the expression is a continue statement.

Parameters: a parameter is a data structure that represents a pointer to a value constructed from a set of bytes. This value may be allocated on a stack segment, a data segment, or a heap segment. The parameter structure must have the following fields:

1. the parameter must have a field storing the name of the parameter that uniquely identifies the parameter within the scope of defining the parameter.

2. The parameter must store a pointer to the package containing the parameter.

3. The parameter must store a boolean value that is used to inform the virtual machine whether the parameter is declared in a function or a global variable.

4. The parameter must store a boolean flag that tells the virtual machine whether the value of the parameter will be escape into the heap (see escape analysis [5 ]).

5. The parameters require fields to store the file name and file line that define it.

6. In order to correctly interpret the bytes stored on any memory segment, parameters need to be associated with the type. The type may be the following original type: a 32-bit or 64-bit integer, a 32-bit or 64-bit floating point number, a boolean value, a string or byte, or a combination of primitive types obtained by using a data structure. In addition, any of these data types may be grouped into arrays or slices, and programmers may also use pointers to handle the values themselves or references thereto (their memory addresses).

7. The parameter needs to store an offset that represents the address in which the virtual machine can find the value represented by the parameter.

8. The parameters need to store the set of operations that must be performed by the virtual machine in order to correctly retrieve the values in memory using the offset as a starting point. For example, a pointer to a field of a structure instance needs to consider a dereferencing of the pointer before considering the byte offset needed to reach the address where the value of the field is located.

9. The parameter must store the size of the value it points to so that the virtual machine can know how many bytes it needs to read from memory.

10. The parameter must store a set of values that indicate how the virtual machine programmer declares the type of parameter. The set of values may assist the compiler in determining whether a compile-time error exists in the source code.

11. Since parameters may represent different data structures, such as arrays, slices, structure instances, pointers, global or local variables, etc., the structure requires different fields to track how the virtual machine will access its values. These fields are grouped and described in the following subsections:

(1) Array: if values accessed through an index of an array or slice are to be represented, the parameter structure needs to store a set of lengths (sizes, if multi-dimensional arrays) representing the total size of the array and a set of indices indicating which particular value the virtual machine is accessing.

(2) Slicing: if a slice is to be represented, the parameter structure requires only a Boolean flag to inform the virtual machine that it needs to treat the parameter as a slice rather than an array.

(3) A pointer: if a value accessed by a reference (pointer) is to be represented, the parameter structure requires a Boolean flag to inform the virtual machine whether the parameter needs to be treated as a pointer. The parameter structure also needs to track how many indirection levels the parameter is handling, e.g. if a parameter represents the pointer of the pointer, then its indirection level will be equal to 3. In relation to the indirection level, the parameter structure needs to keep track of how many times the dereferencing of the parameter is performed, i.e. how many indirection levels are accessed. The parameter cannot be a pointer type, but the programmer may decide to create a pointer from it; this is handled by a boolean flag that tells the virtual machine to use the address to which the parameter points, rather than its actual value, i.e. the parameter is passed by reference.

(4) Data structure instance: if the data structure is to be represented, the parameters must store pointers to custom types that the virtual machine will use to see how to access the values in memory, as well as the parameter set used to define the fields that need to be accessed.

Interactive programming: the process of converting source code into the above-described set of structures allows the virtual machine to conveniently provide interactive programming functionality. One of the methods of interactively executing the program build process can be implemented by adding, deleting or modifying structure instances in the program using REPL, where a user can select a structure present in the program and can modify its properties. This process is different from any other REPL of other programming languages. Conventional REPL adds only new definitions and cannot delete or modify definitions that have been added to a program. The virtual machine described in this document accepts meta-commands independent of the programming language used to build the program:

a. selecting: and a meta-command informing the virtual machine of selecting the program structure to be modified.

b. Deletion: and a meta-command informing the virtual machine to delete certain elements from the program structure or the whole program structure.

c. And (3) adding: the process is performed by writing definitions and statements, as is done when source code is written in any programming language compatible with the virtual machine; in conjunction with the select meta-command, the programmer can decide where their addition should take effect.

d. Debugging: the meta-command tells the virtual machine to provide meta-information about the program, such as the values of local variables, operators or functions on the call stack, and values used as inputs to these functions, as well as the current abstract syntax tree of the program.

e. Step by step: meta-command tells the virtual machine how many program instructions or steps should be run; the virtual machine accepts a timing step, wherein an instruction is run every N seconds; and the virtual machine accepts a negative step in which the program state is reversed a certain number of steps.

And (3) meta programming: virtual machines provide meta-programming capability through a function called "availability". This function is based on the affordability concept proposed by James Gibson [6]. Availability allows a programmer to perform functions on elements or execute element functions at runtime. The programmer must define a rule set that acts as a program structure filter and then can query or inform the filtered program structure to perform or perform functions on its functions, respectively, as shown in fig. 1. For example, the program may filter all structures by number of elements and select only those structures having at least one field of a particular type. The filtered program elements may then be printed to a user, who may select elements therein for use by the availability mechanism of the virtual machine. As previously mentioned, there are two types of availability: functions of a program structure and functions on a program structure. Possible functions of parameters: it is used to replace another parameter, added as a new field to the structure, and its value is printed. Possible functions on parameters: replacing a parameter with another parameter, replacing a parameter with an expression, replacing a parameter with a call to a function, and altering the type of parameter. Fig. 2 and 3 show all functions of the program structure and all functions on the program structure identified by the virtual machine, respectively.

Serializing: the memory in the virtual machine active program is divided into four memory segments, code, stack, data and heap memory segments, as shown in fig. 4.

A) Code segment: this section is represented by the different program structure described above.

B) Stack section: this section is dedicated to storing the bytes required for each function call that occurs during program execution.

C) Data segment: this section stores all global variables present in each package of the program as well as the original literals in the source code.

D) Stacking: this segment stores objects that are allocated at runtime by different data constructs (e.g., pointers and slices).

All memory segments are stored in the memory field of the program structure. However, the virtual machine may also accept a serialized version of the program, where all code segments are converted into byte arrays and eventually merged into a single byte array representing the complete program. This serialized representation of the program may also be used as a bytecode version of the program in which performance optimization is performed, with the virtual machine executing the program by reading directly from the program serialization.

In order to convert a program from its structural representation to its serialized representation, it is necessary to convert the structure to another structure having only integer type fields. These fields can only represent one of three cases: an integer or boolean value, an offset of the byte array in which a particular program element may be found, or an element count telling the virtual machine how many elements need to be read from the byte array. All of the serialized program elements are grouped by their type (program, structure, function, package, expression or parameter) and allocated in byte array order. The virtual machine uses the index structure to know how much it can shift in the byte array to find some type of structure. For example, all packages may start from byte #500, followed by all functions, which start from byte # 1000. In addition to all program structures, strings (e.g., parameter names) and integers (e.g., array lengths) used as fields in the program structures are serialized into their own structure types.

During serialization, the container structure is used to temporarily store all structures being serialized. This container also keeps track of which structures have been serialized through the use of mapping data structures. If a structure has been serialized (e.g., a global variable) and another instance of the global variable is found later, the virtual machine can learn that it has been serialized by looking at the mapping in the container structure, thus using references to the same serialized structure. All structures used in this serialization process are shown in the following table:

serialization parameters

Serialization program

/>

Serialization expression

Field ID	Field name	Type(s)
			1	Operator offset	Integer number
2	Is Native	Integer number
			3	Function code	Integer number
4	Input offset	Integer number
			5	Input count	Integer number
5	Output offset	Integer number
			7	Output count	Integer number
8	Label offset	Integer number
			9	Label size	Integer number
10	The Then line	Integer number
			11	Else line	Integer number
12	Range	Integer number
			13	Is a method call	Integer number
14	Is a structural text	Integer number
			15	Is an array of characters	Integer number
16	Is an undefined type	Integer number
			17	Is Break	Integer number
18	Is a continuous	Integer number
			19	Function offset	Integer number
20	Package offset	Integer number

Container

Field ID	Field name	Type(s)
			1	Index	Index
2	Procedure	Serialization program
			3	Program package	[]Serialization package
4	Package mapping	Mapping [ character string ]]Integer number
			5	Structure of the	[]Serialization structure
5	Structure mapping	Mapping [ character string ]]Integer number
			7	Function of	[]Serialization function
8	Function mapping	Mapping [ character string ]]Integer number
			9	Expression type	[]Serialization expression
10	Parameters (parameters)	[]Serialization parameters
			11	Calling	[]Serialized calls
12	Name of the name	[]Bytes
			13	Name mapping	Mapping [ character string ]]Integer number
14	Integer number	[]Integer number
			15	Memory	[]Bytes

Serialization function

Field ID	Field name	Type(s)
			1	Name offset	Integer number
2	Name size	Integer number
			3	Input offset	Integer number
4	Input count	Integer number
			5	Output offset	Integer number
5	Output count	Integer number
			7	Expression offset	Integer number
8	Expression counting	Integer number
			9	Size and dimensions of	Integer number
10	Length of	Integer number
			11	Pointer list offset	Integer number
12	Pointer list counting	Integer number
			13	Current expression offset	Integer number
14	Package offset	Integer number

Serialization package

Field ID	Field name	Type(s)
			1	Name offset	Integer number
2	Name size	Integer number
			3	Introducing an offset	Integer number
4	Import count	Integer number
			5	Structural offset	Integer number
5	Structure counting	Integer number
			7	Global offset	Integer number
8	Global counting	Integer number
			9	Function offset	Integer number
10	Function count	Integer number
			11	Current function offset	Integer number
12	Current structural offset	Integer number

Index

Field ID	Field name	Type(s)
			1	Program offset	Integer number
2	Calling an offset	Integer number
			3	Package offset	Integer number
4	Structural offset	Integer number
			5	Function offset	Integer number
5	Expression offset	Integer number
			7	Parameter offset	Integer number
8	Integer offset	Integer number
			9	String offset	Integer number
10	Memory offset	Integer number

Serialization structure

Field ID	Field name	Type(s)
			1	Name offset	Integer number
2	Name size	Integer number
			3	Field offset	Integer number
4	Field counting	Integer number
			5	Size and dimensions of	Integer number
5	Package offset	Integer number

Serialized calls

Field ID	Field name	Type(s)
			1	Operator offset	Integer number
2	Row of lines	Integer number
			3	Frame pointer	Integer number

Blockchain-based distributed applications: in order to use a distributed application of a virtual machine, a programmer needs to initialize a blockchain database with program states that are generated by running a program represented by "blockchain code". After initializing a blockchain-based distributed application, a user may query the stored program state and merge the program state into another piece of code called "transactional code".

The function of "blockchain code" is similar to a programming language library: it defines a series of subroutines (functions), types (structures), and variables, and can be imported into the program. The distinction between blockchain code and library is as follows:

1) For initializing a blockchain-based distributed application.

2) The global variables defined in the packages that make up the blockchain code are used as program states for the blockchain-based distributed application.

3) It includes a master (entry point) function that is used to initialize the program state of a blockchain-based distributed application.

4) After initializing the program state, the master function is removed from the blockchain code.

Program states of a blockchain-based distributed application may be generated by serializing a program represented by blockchain code. The serialization includes all blockchain code except the master function that is used only to initialize the program state of the distributed application. The program state is stored on the blockchain as part of the unused output of the transaction.

The entire program state may be queried or altered. Code segments representing blockchain code are also part of the program state. By using this design, the code of the distributed application can be modified. Availability may be used to modify modification of the distributed application code segments.

The program state of the blockchain-based distributed application is equivalent to the serialization of the initialized blockchain code and its primary function is subtracted. The serialized structure consists of four memory segments: code, stack, data, and heap. The code segments represent source code in the blockchain code; the stack segment represents a stack of the program in which local variables of different function calls executed when the program is run are stored; the data segment stores all global variables and original text found in the source code; finally, heap segments store objects (strings and slices) that can be scaled down or expanded in size, objects pointed to by pointers, and objects that escape their function call scope (see escape analysis [5 ]).

Program states stored on the blockchain may be altered or queried by running a program that "imports" the program state. To be able to access the program state, the program needs to import a package stored in the program state.

Both the program state and the transactions running for that program state are stored as a serialization of the program. To run transactions for program state, two serialized merges need to be performed. This combination results in a structure similar to that shown in fig. 5.

It can be seen that each memory segment of the transactional code serialization is appended to the end of each memory segment of the blockchain code serialization. The merging of the two serializations results in serialization, which represents a procedure that contains both blockchain and transactional code.

After running the combined program, the program needs to be split into two parts again: program state and serialized transaction code, where the new program state is stored as part of the unused output and the serialized transaction code is stored as part of the transaction.

Reference to the literature

[1]Smith,James E.,and Ravi Nair.“The architecture of virtual machines.”Computer 38.5(2005):32-38.

[2]Burger,Alexander.“The PicoLisp Reference.”(2013).

[3]Hickey,Rich.“The Clojure programming language.”Proceedings of the 2008symposium on Dynamic languages.ACM,2008.

[4]Odersky,Martin,et al.An overview of the Scala programming language.No.REP_WORK.2004.

[5]Choi,Jong-Deok,et al.“Escape analysis for Java.”AcmSigplan Notices 34.10(1999)：1-19.

[6]Gibson,James Jerome.“The senses considered as perceptual systems.”(1966).

It is to be understood that the above-described embodiments of the present invention are merely illustrative of or explanation of the principles of the present invention and are in no way limiting of the invention. Accordingly, any modification, equivalent replacement, improvement, etc. made without departing from the spirit and scope of the present invention should be included in the scope of the present invention. Furthermore, the appended claims are intended to cover all such changes and modifications that fall within the scope and boundary of the appended claims, or equivalents of such scope and boundary.

Claims (8)

1. A virtual machine that parses source code into a set of structure storage fields representing different portions of a virtual machine program, the fields of the set of structure storage fields representing features of a program component, the set of structure storage fields comprising one or more of: program root structure, function calls in call stack, program package, data structure, functions, expressions, and parameters;

the program root structure stores metadata about a program; the function call in the call stack is distributed on the call stack of the virtual machine, and represents the function call in the program being executed by the virtual machine; the program package is used for packaging or grouping other structures used by the virtual machine, and the name used as the unique identifier of the program package is stored in the program of the virtual machine; the data structure, used by the program, comprises at least a data structure defined by a set of parameters, and a name used as its unique identifier in the package, the data structure storing a reference to the package in which it is packaged; the function, a subroutine in a program running in a virtual machine, has code for identifying whether the function is part of a standard function library of the virtual machine, and the function structure includes: a name serving as a unique identifier in a package containing the function structure, a parameter set serving as a function input, a parameter set serving as a function output, an expression set or a statement set; the expression comprises an input set and an output set to be used by a calling function, a pointer pointing to the function to be executed by using the input and the output, a label uniquely identifying the expression in the function definition, and a pointer pointing to the function and a program package; the parameter represents a pointer to a value constructed from a set of bytes, associated with a type, the parameter comprising the following fields: a field storing a parameter name, a field storing a pointer, a field storing a boolean value, a field storing a boolean flag, a field storing a file name and a file row defining parameters, a field storing an offset, a field storing a set of operations that have to be performed by the virtual machine, a field storing the size of the pointed value, a field storing a set of values, and a field representing different data structures.

2. An interactive programming method for a virtual machine, wherein the virtual machine of claim 1 is operated to parse source code into a set of structure storage fields representing different parts of a virtual machine program; constructing meta-commands in a read-evaluate-print loop (REPL) that is independent of the programming language used by the build program for the virtual machine; modifying a program structure using a meta-command in a constructed read-evaluate-print loop (REPL), the meta-command comprising:

selecting, informing the virtual machine of selecting a program structure to be modified;

deleting, informing the virtual machine to delete certain elements from the program structure or the whole program structure;

adding, namely determining the adding position by writing definitions and sentence execution and combining a selection element command;

debugging, informing a virtual machine to provide meta information about a program;

step by step, the virtual machine is informed of how many program instructions or steps should be run.

3. A method of meta-programming a virtual machine, wherein running the virtual machine of claim 1 or 2 parses source code into a set of structure storage fields representing different parts of the virtual machine program; constructing a programming paradigm of availability to perform functions on elements or perform element functions; constructing a rule set used as a program structure filter, and querying or notifying the filtered program structure; the modification is done by a programming paradigm of availability.

4. A method for serializing a program structure of a virtual machine, wherein the virtual machine of claim 1 or 2 is operated to parse source code into a set of structure storage fields representing different parts of the virtual machine program; converting the program from its structural representation to another structure having only integer type fields; all the serialized program elements are grouped according to the types and distributed according to the sequence of byte arrays; the virtual machine obtains the offset in the byte array by using the index structure; constructing a container structure for temporarily storing all structures being serialized, during serialization, temporarily storing all structures being serialized by the container structure; merging all byte arrays results in a single byte array for the complete program.

5. The method of serializing a program structure of a virtual machine according to claim 4, wherein the other structured fields having integer type fields can only represent one of three cases: an integer or boolean value, an offset of the byte array in which a particular program element is found, or an element count telling the virtual machine how many elements need to be read from the byte array.

6. A method of interoperation of a virtual machine's blockchain-based distributed applications, characterized by initializing a blockchain database with program states generated by running a program represented by blockchain code; the blockchain code includes a master function for initializing a program state of the blockchain-based distributed application, the master function being removed from the blockchain code after initializing the program state, global variables defined in a package constituting the blockchain code being used as the program state of the blockchain-based distributed application; generating program states of the blockchain-based distributed application by serializing the program represented by the blockchain code, the serialization method being the serialization method of claim 4; querying or modifying the entire program state; storing the program state and the transaction running for the program state as the serialization of the program, executing the combination of the two serialization, and attaching each memory segment of the transaction code serialization to the end of each memory segment of the blockchain code serialization; after running the combined program, the program is split into two parts: program state and serialized transaction code, where the new program state is stored as part of the unused output and the serialized transaction code is stored as part of the transaction.

7. The method of interoperation of a virtual machine's blockchain-based distributed application of claim 6, wherein the method of querying or altering the overall program state is to modify a code segment of the distributed application using a programming paradigm of availability.

8. The method of interoperation of a virtual machine's blockchain-based distributed application of claim 6, wherein the method of querying or altering the overall program state is by importing a package stored in the program state.