Content deleted Content added
WP:CHECKWIKI error fix #94. Stray ref tag. Do general fixes and cleanup if needed. -, typo(s) fixed: Arguement → Argument (17), equivilent → equivalent, fundemental → fu using AWB (12082) |
|||
| (37 intermediate revisions by 18 users not shown) | |||
Line 1:
'''
▲'''Toy''' is an imperative, type-sensitive language that provides the basic functionality of a programming language. The language was designed and developed from the ground-up by Paul Longtine.<ref>https://github.com/bannana/language/blob/master/doc/OVERVIEW</ref> Written in C, Toy was created with the intent to be an educational experience and serves as a learning tool (or toy, hence the name) for those looking to familiarize themselves with the inner-workings of a programming language.<ref>https://banna.tech/projects/post/toy_language/</ref>
== Specification<ref>{{cite web|url=https://github.com/bannana/language/blob/master/doc/SPECIFICATION|title=bannana/language|website=[[GitHub]]|date=17 February 2021|publisher=}}</ref><ref>{{Cite web|url=http://dev.nanner.co/language/file/doc/SPECIFICATION.html|title=SPECIFICATION - language - some fools attempt at an interpreted language}}</ref> ==
=== [[Type (computer science)|Types]] ===
0 VOID - Null, no data
1 ADDR - Address type (bytecode)
Line 22 ⟶ 21:
15 G_FIFO - Stack
=== [[Run time (program lifecycle phase)|Runtime]] ===
==== Runtime context definition ====
Line 28 ⟶ 27:
The runtime context keeps track of an individual threads metadata, such as:
* The operating [[Stack (abstract data type)|stack]]
** The operating stack where current running instructions push/pop to.
* Namespace instance
** Data structure that holds the references to variable containers, also proving the interface for Namespace Levels.
* Argument stack
** Arguments to function calls are pushed on to this stack, flushed on call.
* Program counter
** An interface around bytecode to keep track of traversing line-numbered instructions.
This context gives definition to an 'environment' where code is executed.
==== [[Namespace]] definition ====
A key part to any operational computer language is the notion of a 'Namespace'.
Line 65 ⟶ 64:
Scopes are handled by referencing to either the Global Scope or the Local Scope.
The Local Scope is denoted by '0' in the scope argument when referring to names,
and this scope is initialized when evaluating any new block of code. When a different block of code is called, a new scope is added as a new Namespace level. Namespace levels act as context switches within function contexts. For example, the local namespace must be 'returned to' if that local namespace context needs to be preserved on return. Pushing 'Namespace levels' ensures that for every ''n'' function calls, you can traverse ''n'' instances of previous namespaces. For example, take this namespace level graphic, where each Level is a namespace instance:
Level 0: Global namespace, LSB == '1'.
Line 77 ⟶ 76:
Level 2: Namespace level, where Local Level is at 2, LSB == '0'.
Global scope names (LSB == 1 in the scope argument) are
names declared in the global scope. The "Local Level" is at where references
that have a scope argument of '0' refer to when accessing names.
Line 87 ⟶ 85:
by using the
==== [[Variable (computer science)|Variable]] definition ====
Variables in this
* Provide a distinguishable area of typed data
Line 117 ⟶ 115:
structures.
==== [[Function (computer science)|Function]] definition ====
Functions in this virtual machine are a pointer to a set of instructions in a
program with metadata about parameters defined.
==== [[Object (computer science)|Object]] definition ====
In this paradigm, objects are units that encapsulate a separate namespace and
collection of methods.
==== [[Bytecode]] spec ====
Bytecode is arranged in the following order:
Where the <opcode> is a single byte denoting which subroutine to call with the
Line 137 ⟶ 135:
lengths, some having 0 arguments, and others having 3 arguments.
A bytecode instruction is a single-byte opcode, followed by at maximum 3
arguments, which can be in the following forms:
Below is the specification of all the instructions with a short description for
each instruction, and instruction category:
=== [[Opcode]] ===
Keywords:
TOS - 'Top Of Stack' The top element
TBI - 'To be Implemented'
S<nowiki><[variable]></nowiki> - Static Argument.
N<nowiki><[variable]></nowiki> - Name.
A<nowiki><[variable]></nowiki> - Address Argument.
D<nowiki><[variable]></nowiki> - Dynamic bytecode argument.
----
Hex |
These subroutines operate on the current-working stack(1).
----
10 POP S<nowiki><n></nowiki> - pops the stack n times.
11 ROT - rotates top of stack
12 DUP - duplicates the top of the stack
13 ROT_THREE - rotates top three elements of stack
20 DEC S<nowiki><scope></nowiki> S<nowiki><type></nowiki> N - declare variable of type
▲'''3 - Type management'''
Types are in the air at this moment. I'll detail what types there are when
the time comes
----
30 [[typeof|TYPEOF]] - pushes type of TOS on to the stack TBI
31 CAST S<nowiki><type></nowiki> - Tries to cast TOS to <nowiki><type></nowiki> TBI
OPS take the two top elements of the stack,
the result on the stack.
----
Line 209 ⟶ 207:
4D OR - or's TBI
4E XOR - xor's TBI
4F NAND - and's TBI
Things for comparison, < > = ! and so on and so forth.
Line 226 ⟶ 224:
57 OR - Boolean OR
58 AND - Boolean AND
60 STARTL - Start of loop
61 CLOOP - Conditional loop. If TOS is true, continue looping, else break
6E BREAK - Breaks out of loop
6F ENDL - End of loop
These instructions dictate code flow.
----
70 [[GOTO]] A<nowiki><addr></nowiki> - Goes to address
71 JUMPF A<nowiki><n></nowiki> - Goes forward <n> lines
72 IFDO - If TOS is TRUE, do until done, if not, jump to done
73 ELSE - Chained with an IFDO statement, if IFDO fails, execute ELSE
Line 248 ⟶ 245:
7E DONE - End of block
7F CALL N - Calls function, pushes return value on to STACK.
'''8 - Generic object interface. Expects object on TOS'''▼
80 GETN N<name> - Returns variable assosiated with name in object▼
81 SETN N<name> - Sets the variable assosiated with name in object▼
Object on TOS, Variable on TOS1
82 CALLM N<nowiki><name></nowiki> - Calls method in object▼
83 INDEXO - Index an object, uses argument stack▼
84 MODO S<nowiki><OP></nowiki> - Modify an object based on op. [+, -, *, /, %, ^ .. etc.]▼
==== F - Functions/classes ====▼
▲ 82 CALLM N<name> - Calls method in object
FF DEFUN NS<nowiki><type></nowiki> D<nowiki><args></nowiki> - Un-funs everything. no, no- it defines a▼
▲ 83 INDEXO - Index an object, uses argument stack
function. D is its name, S<nowiki><type></nowiki> is▼
the return value, D<nowiki><args></nowiki> is the args.▼
▲ 84 MODO S<OP> - Modify an object based on op. [+, -, *, /, %, ^ .. etc.]
▲F - Functions/classes
▲ FF DEFUN NS<type> D<args> - Un-funs everything. no, no- it defines a
▲ function. D is its name, S<type> is
▲ the return value, D<args> is the args.
FE DECLASS ND<args> - Defines a class.
FD DENS S - Declares namespace▼
F1 NEW S<scope> N - Instantiates class▼
==== Special Bytes ====
▲ FD DENS S - Declares namespace
00 [[Null character|NULL]] - No-op▼
01 LC N<nowiki><name></nowiki> - Calls OS function library, i.e. I/O, opening files, etc. TBI▼
▲ F2 ENDCLASS - End of class block
▲ F1 NEW S<scope> N - Instantiates class
▲ F0 RETURN - Returns from function
▲ 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.
03 DEBUG - Toggle debug mode
0E ARGB - Builds argument stack
0F PC S - Primitive call, calls a subroutine A. A list of TBI▼
▲ 0F PC S - Primitive call, calls a subroutine A. A list of TBI
primitive subroutines providing methods to tweak
objects this bytecode set cannot touch. Uses argstack.
=== [[Compiler|Compiler/Translator/Assembler]] ===
==== [[Lexical analysis]] ====
Going from code to bytecode is what this section is all about. First off an
abstract notation for the code will be broken down into a binary tree as so:
<nowiki><node></nowiki>
/\
/ \
/ \
<nowiki><arg></nowiki> <nowiki><next></nowiki>
node> can be an argument of its parent node, or the next instruction.
Line 329 ⟶ 311:
null 3
Functions are expressed as individual [[binary trees]]. The root of any file is
treated as an individual binary tree, as this is also a function.
The various instruction nodes are as follows:
* def <nowiki><type></nowiki> <nowiki><name></nowiki>
** Define a named space in memory with the type specified
*** See the 'TYPES' section under 'OVERVIEW'
Line 343 ⟶ 325:
The various instruction nodes within the tree will call specific functions
that will take
correct bytecode equivalent.
== Developer's Website ==
The developer of the language, Paul Longtine, operates a publicly available website and blog called [http://banna.tech banna.tech], named after his online alias 'banna'.
==References==
{{Reflist}}
[[Category:Programming language topics|Specification]]
| |||