Welcome
Welcome to xX Project!
The purpose of this project is to create a virtual machine (interpreter) for an interpreted high-level dynamically-typed objected-oriented language. Coupled with a well-defined comprehensive library, xX would provide a portable cross-platform programming and run-time environment. Ultimately, xX will serve as a personal study of virtual machines.
I would like to implement xX in three layers: the xX (pronounced double-x) programming language, the xX common language, and the xX virtual machine.
xX
The xX programming language will be a high-level dynamically-typed object-oriented programming language and will certainly be the common language for programmers. Honestly, I haven't given xX much thought since I need to develop xXasm first. xX code would actually need to be compiled into xXasm code.
xXasm
The xXasm programming language will be a low-level stack-language composed of operators and operands entered in reverse-polish notation. For example, an instruction to add two numbers my look like this: 2 5 add. xXasm will be to the xX virtual machine what assembler is to a CPU. With the exception that xXasm code will be executed directly by the xX virtual machine instead of being processed by an assembler to produce byte-code. In addition, xXasm will be object-aware!
xX Virtual Machine
The xX virtual machine (xXvm) will be a stack-machine featuring at least one stack, but most likely two, and possibly a dictionary. xXvm will be able to execute xXasm code directly similar to how PostScript software and printer firmware execute PostScript code. xXvm will support numerous instructions and will have the capability of loading extensions via standard C library-loading facilities. One strategy I would like to try is to implement object-oriented concepts at the operator (opcode) level. This means xX will be entirely object-oriented down to xXvm! The stack will not hold data but rather pointers to objects. My hope is to implement xX in a way what it is object-ware and able to handle any object xXasm can throw at it!
Take for instance the following xXasm instructions: 2 2 add. Each token will be considered an instruction. Upon receiving literals such as '2', xXvm will push them into the stack. The add operator will instruct xXvm to add the last two stack objects. But... how will it add them? Note I said 'add the last two objects.' xXvm will be able to determing the object type and execute the appropriate add function. How will it do this? Well, each object will have a type associated with it. As for the function? Heck, I don't know, yet. Most likely, it will involved a callback function.
Regardless, sound like fun!
The purpose of this project is to create a virtual machine (interpreter) for an interpreted high-level dynamically-typed objected-oriented language. Coupled with a well-defined comprehensive library, xX would provide a portable cross-platform programming and run-time environment. Ultimately, xX will serve as a personal study of virtual machines.
I would like to implement xX in three layers: the xX (pronounced double-x) programming language, the xX common language, and the xX virtual machine.
xX
The xX programming language will be a high-level dynamically-typed object-oriented programming language and will certainly be the common language for programmers. Honestly, I haven't given xX much thought since I need to develop xXasm first. xX code would actually need to be compiled into xXasm code.
xXasm
The xXasm programming language will be a low-level stack-language composed of operators and operands entered in reverse-polish notation. For example, an instruction to add two numbers my look like this: 2 5 add. xXasm will be to the xX virtual machine what assembler is to a CPU. With the exception that xXasm code will be executed directly by the xX virtual machine instead of being processed by an assembler to produce byte-code. In addition, xXasm will be object-aware!
xX Virtual Machine
The xX virtual machine (xXvm) will be a stack-machine featuring at least one stack, but most likely two, and possibly a dictionary. xXvm will be able to execute xXasm code directly similar to how PostScript software and printer firmware execute PostScript code. xXvm will support numerous instructions and will have the capability of loading extensions via standard C library-loading facilities. One strategy I would like to try is to implement object-oriented concepts at the operator (opcode) level. This means xX will be entirely object-oriented down to xXvm! The stack will not hold data but rather pointers to objects. My hope is to implement xX in a way what it is object-ware and able to handle any object xXasm can throw at it!
Take for instance the following xXasm instructions: 2 2 add. Each token will be considered an instruction. Upon receiving literals such as '2', xXvm will push them into the stack. The add operator will instruct xXvm to add the last two stack objects. But... how will it add them? Note I said 'add the last two objects.' xXvm will be able to determing the object type and execute the appropriate add function. How will it do this? Well, each object will have a type associated with it. As for the function? Heck, I don't know, yet. Most likely, it will involved a callback function.
Regardless, sound like fun!
posted by eR at 5:43 PM
0 Comments:
Post a Comment
<< Home