Toi (programming language): Difference between revisions

Revision as of 06:52, 24 October 2016

Revision as of 07:38, 24 October 2016

Line 24:

=== Runtime ===

==== RUNTIMERuntime CONTEXTcontext DEFINITIONdefinition ====

The runtime context keeps track of aan individual threads metadata, such as:

* The operating stack

Line 34:

** Data structure that holds the references to variable containers, also proving the interface for Namespace Levels.

*** refer to NAMESPACE DEFINITION

* ArguementArgument stack

** Arguments to function calls are pushed on to this stack, flushed on call.

*** refer to STACK DEFINITION, FUNCTION DEFINITION

Line 43:

This context gives definition to an 'environment' where code is executed.

==== NAMESPACENamespace DEFINITIONdefinition ====

A key part to any operational computer language is the notion of a 'Namespace'.

Line 58:

* Implicitly move in/out of scopes

The scope arguementargument is a single byte, where the format is as follows:

Namespace|Scope

Line 77:

Level 2: Namespace level, where Local Level is at 2, LSB == '0'.

Global scope names (LSB == 1 in the scope arguementargument) are persistient

through the runtime as they handle all function definitions, objects, and

names declared in the global scope. The "Local Level" is at where references

that have a scope arguementargument of '0' refer to when accessing names.

The Namespace arguementargument refers to which Namespace the variable exists in.

When the namespace arguementargument equals 0, the current namespace is referenced.

The global namespace is 1 by default, and any other namespaces must be declared

by using the

==== VARIABLEVariable DEFINITIONdefinition ====

Variables in this definiton provide the following mechanims:

Line 93:

* Provide a distinguishable area of typed data

* Provide a generic container around typed data, to allow for labeling

* Declare a set of fundementalfundamental datatypes, and methods to:

** Allocate the proper space of memory for the given data type,

** Deallocate the space of memory a variables data may take up, and

Line 110:

scope in terms of ___location within a given set of scopes. This is what is called

'Ownership'. In a given runtime, variable containers can exist in the following

structures: A stack instance, Bytecode arguementsarguments, and Namespaces

The concept of ownership differentiates variables existing on one or more of the

Line 117:

structures.

==== FUNCTIONFunction DEFINITIONdefinition ====

Functions in this virtual machine are a pointer to a set of instructions in a

program with metadata about parameters defined.

==== OBJECTObject DEFINITIONdefinition ====

In this paradigm, objects are units that encapsulate a seperateseparate namespace and

collection of methods.

==== BYTECODEBytecode SPECspec ====

Bytecode is arranged in the following order:

Line 134:

Where the <opcode> is a single byte denoting which subroutine to call with the

following arguementsarguments when executed. Different opcodes have different arguementargument

lengths, some having 0 arguementsarguments, and others having 3 arguementsarguments.

'''Interpreting Bytecode Instructions'''

A bytecode instruction is a single-byte opcode, followed by at maximum 3

arguementsarguments, which can be in the following forms:

* Static (single byte)

Line 148:

** i.e. FF FF 00 <0xFFFF bytes of data>,

** 01 00 <0x1 bytes of data>,

** 06 00 <0x6 bytes of data>, etc.

Below is the specification of all the instructions with a short description for

Line 158:

TOS - 'Top Of Stack' The top element

TBI - 'To be Implemented'

S<[variable]> - Static ArguementArgument.

N<[variable]> - Name.

A<[variable]> - Address ArguementArgument.

D<[variable]> - Dynamic bytecode arguementargument.

----

Hex | Memnonic | arguments - description

Line 176:

'''2 - Variable management'''

----

20 DEC S<scope> S<type> N<ref> - declare variable of type

21 LOV S<scope> N<ref> - loads reference variable on to stack

22 STV S<scope> N<ref> - stores TOS to reference variable

23 CTV S<scope> N<ref> D<data> - loads constant into variable

24 CTS D<data> - loads constant into stack

----

Line 247:

7D ERR - Start error block, uses TOS to evaluate error TBI

7E DONE - End of block

7F CALL N<ref> - Calls function, pushes return value on to STACK.

----

'''8 - Generic object interface. Expects object on TOS'''

Line 258:

82 CALLM N<name> - Calls method in object

83 INDEXO - Index an object, uses arguementargument stack

84 MODO S<OP> - Modify an object based on op. [+, -, *, /, %, ^ .. etc.]

----

F - Functions/classes

----

FF DEFUN N<ref>SNS<type> D<args> - Un-funs everything. no, no- it defines a

function. D<ref> is its name, S<type> is

the return value, D<args> is the args.

FE DECLASS N<ref>DND<args> - Defines a class.

FD DENS S<ref> - Declares namespace

F2 ENDCLASS - End of class block

F1 NEW S<scope> N<ref> - Instantiates class

F0 RETURN - Returns from function

Line 282:

00 NULL - No-op

01 LC N<name> - Calls OS function library, i.e. I/O, opening files, etc. TBI

02 PRINT - Prints whatever is on the TOS.

Line 288:

03 DEBUG - Toggle debug mode

0E ARGB - Builds arguementargument stack

0F PC S<ref> - Primitive call, calls a subroutine A<ref>. A list of TBI

primitive subroutines providing methods to tweak

objects this bytecode set cannot touch. Uses argstack.

Line 296:

=== Compiler/Translator/Assembler ===

==== LEXICALLexical ANALYSISanalysis ====

Going from code to bytecode is what this section is all about. First off an

Line 344:

The various instruction nodes within the tree will call specific functions

that will take arguemets specified and lookahead and lookbehind to formulate the

correct bytecode equivilentequivalent.

==References==