From ccc11c810d66c5847448293551cafd389f6e4508 Mon Sep 17 00:00:00 2001 From: Kyle Gunger Date: Wed, 1 Dec 2021 21:36:31 -0500 Subject: [Readme] links and format updates --- spec/1 - language.md | 525 --------------------------------------------------- spec/1.md | 525 +++++++++++++++++++++++++++++++++++++++++++++++++++ spec/2 - related.md | 111 ----------- spec/2.md | 111 +++++++++++ spec/3 - abi.md | 17 -- spec/3.md | 17 ++ spec/4 - fip.md | 63 ------- spec/4.md | 63 +++++++ spec/README.md | 15 +- 9 files changed, 724 insertions(+), 723 deletions(-) delete mode 100644 spec/1 - language.md create mode 100644 spec/1.md delete mode 100644 spec/2 - related.md create mode 100644 spec/2.md delete mode 100644 spec/3 - abi.md create mode 100644 spec/3.md delete mode 100644 spec/4 - fip.md create mode 100644 spec/4.md (limited to 'spec') diff --git a/spec/1 - language.md b/spec/1 - language.md deleted file mode 100644 index 47e6834..0000000 --- a/spec/1 - language.md +++ /dev/null @@ -1,525 +0,0 @@ -# The Language - -## Section 1 - Files - -### Folder Structure - -Normal TNSL project structure has a root source folder with TNSL files contained within the folder and sub-folders. It is normal for the root folder to represent a single library or binary, although there is no strict rule enforcing this. Standard organization is to place sub-modules in sub-folders. The file name for the module entry point should match the folder name. - -The file representing the compile target is known as the root file, which generally resides in the root source folder. This file will contain a main method, and/or the pre-processor statement `rootfile` to denote the root of a library. If both are present, the compiler will generate an executable by default unless the `--otype` flag is set to `library` or `tlet`. - -### TNSL Files - -TNSL files end with the `.tnsl` extension and may contain the following: -- Comments -- Pre-processor statements -- Modules -- Constant and variable definitions -- Named function blocks -- Struct definitions -- Method and interface blocks - -The following may only occur within named function or method blocks: -- Re-assignment of variables -- Control flow blocks -- Function calls -- Anonymous blocks (Scope blocks) - -## Section 2 - Blocks - -### TNSL Block Notation - -Blocks in tnsl consist of a slash `/` and a character denoting the type of block. The reverse of these symbols end the block. The three types of blocks are comment, pre-processor, and code. Code blocks can be further broken down into modules, functions, control flow, methods, and interfaces. - - Examples of standard block opening and closing characters: - - /# - open comment - #/ - close comment - - /: - open pre-processor - :/ - close pre-processor - - /; - open code - ;/ - close code - -In addition to the standard opening and closing characters, there exist "swivel" character sets to quickly close and open a block type - - ;; - close code, then open code - #; - close comment, open code - ;# - close code, open comment - :: - close pre-processor, open preprocessor - #: - close comment, open pre-processor - :# - close pre-processor, open comment - -### Modules - -Modules are akin to namespaces in C++ - -They hold a group of related modules, functions, structs, and variables. These named definitions may be used by other projects if the `export` keyword is used in conjunction with the `module` keywor; otherwise, the names are not exported into the file's symbol table. - -### Module definition example: - -*File a.tnsl (project a)* - - /; export module pubmod - /; module hidden - # Can access all from pubmod, and pubmod.hidden - ;/ - # Can access all from pubmod, and pubmod.hidden - ;/ - # Can access all from pubmod, and pubmod.hidden - -*File aa.tnsl (project a)* - - /; my_function_a - # Can access all from pubmod, and pubmod.hidden - ;/ - # Can access all from pubmod, and pubmod.hidden - -*File b.tnsl (project b)* - - /; my_function - # Can access all from pubmod, but not pubmod.hidden - ;/ - # Can access all from pubmod, but not pubmod.hidden - -### Functions - -TNSL functions are code blocks whose definition contains none of the following: control flow keywords, the module keyword, the method keyword. TNSL functions are called methods if they are contained within a method block. TNSL methods may only be called with relation to the user defined type they are linked to. If a TNSL function has no user defined name, it is anonymous. Anonymous functions can be stored as void type variables or called immediately. If an anonymous function is not stored, it is interpreted as inline and called immediately (this is known as a scope block). - -Function blocks may have inputs and/or outputs. Inputs are enclosed by `()` and outputs are enclosed by `[]` - -Input lists must begin with a type and conclude with at least one named parameter. If no type is given after a comma, it is assumed that the previous type carries over. - -Output lists consist of a comma seperated list of types. - -Either of these may be omitted for no input and/or output. - -TNSL functions may have their call stack modified by the `raw` and/or `inline` keywords. If the `inline` keyword is placed before the function declaration, the function will still be exported (if it is being exported), but any time it is used in the project's code, it will be optimized as if in-line. - -The use of the `raw` keyword has several effects: the function will have no generated assembly preamble, the function will allow `raw return` statements, the function will not be optimized, and the function will allow `asm` statements. Any function may be labeled `raw`, even `main` and anonymous functions. - -Functions *may* be overloaded (that is, two functions may share names but have differing input type lists). Overloaded functions *may not* share the same inputs and differing outputs, but *may* have both differing inputs and differing outputs. - -Examples: - - # simple function with no inputs or outputs named "my_function" - /; my_function - - ;/ - - # function with inputs and outputs - /; my_second_function ( input1, input2 ) [ , , ... , ] - - ;/ - - # funtion with a scope block - /; my_third_function - - # a scope block - /; - - ;/ - ;/ - -### Control Flow Blocks - -Control flow blocks are code blocks whose definitions contain the keywords if, else, loop, match, case, or default. - -For if, else, loop, and match any inputs and/or outputs are a semicolon-separated list of statements. For case or default, only inputs are accepted in the form of a single value. Any variables defined in these inputs or outputs are scoped to the block only. Control flow blocks may not actually output any values; instead, any statements in the output are evaluated when the block ends, weather it loops or not. - -Examples: - - # simple if block - /; if ( ) - - ;/ - - # if block with else and else if - /; if ( ; ; ... ; ) - - ;; else if ( ) - - ;; else - - ;/ - - # loop block - /; loop ( ; ... ; ) - [ ] - - - ;/ - - # match block - /; match ( ; ... ; ) - - /; case - - ;; case - - # Continue here would fall through to default - ;; default - - ;/ - ;/ - -## Section 3 - Statements - -### TNSL Statement Notation - -There are three types of tnsl statements: code, pre-processor, and comment. Code statements begin with `;` and end at the next statement. Pre-processor statements begin with `:` and end at the next statement. Comment statements (line comments) begin with `#` and end at the next new line. After a line comment ends, the previous statement resumes. - -### Variable Declaration - -Declaring a variable is done by referencing a type and then giving a list of names for the new variables. Optionally, a list of values may be given to initialize the new variables. - -Variables may be augmented by the following keywords: `const`, `volatile`, and/or `static`. - -Declaring a variable as `const` means that it is a constant and must be immediately initialized. A constant may not be re-assigned a value. - -Declaring a variable as `volatile` means that the compiler will not attempt to optimize operations performed on it. - -Declaring a variable `static` means that the value will be kept between function calls. Static variables may create race conditions when paired with threads. - -Examples: - - # list with initialization - ;int a, b = 0, 1 - - # single without initialization - ;int c - - # list with partial initialization - ;int d, e = 0 # d is defined, but e is not - -## Section 4 - Types - -An exhaustive list of built-in types can be found in Appendix B. - -### The `void` Type - -The `void` type represents one of two things: an unknown data type, or a function. When the void type is paired with input and output parameters `void( )[ ]` it represents a function. When it is not paired with these things it represents an unknown data type. - -Pure `void` types can not be created. Function types are *always* references to the function, more like pointers than data holders. Otherwise, void types must be created as pure pointers. In this case, they are in a sense "un-typed" pointers which do not know the length of the object they are pointing at, only the address. - -Examples: - - # simple function - /; func_1 - ;/ - - # void example func - /; func_2 - - # create a void type and assign it func_1's value - ;void()[] func_ref = func_1 - - # call func_1 using func_ref - ;func_ref() - ;/ - -More examples of pointer voids are available in the pointers section of this document. - -### Arrays - -In memory, arrays store their length as a uint, then immediately follow with the contents of the array. This way, all arrays can be checked for length with the `len` operator. - -Arrays are created by prefixing a type with `{ <# of elements> }` or simply `{}` so long as the array is immediately initialized. One can similarly access an element of an array by suffixing the variable name with `{ }`. - -When initializing or assigning a new value to an entire array, use `{}` to encase a list of values. - -The length of the array can be gotten by `len ` - -Examples: - - # create an array of five integers - ;{5}int i - - # assign values to the array - ;i{0} = 0 - ;i{1} = 2 - ;i{2} = 0 - ;i{3} = 2 - ;i{4} = 1 - - # store the length of the array - ;uint array_length = len i - - # create an initialized array with length five - ;{}int j = {1, 2, 3, 4, 5} - - # loop through the array and add them. - /; loop (int k = 0; k < array_length) [k++] - - ;i{k} += j{k} - ;/ - - -### Pointers - -Pointer types are created using the `~` (pointer to) operator. This operator serves as both part of the type, and as a way to get a pointer from a type. To de-reference a pointer into it's base type, use the `` ` `` (de-reference) operator. - -Passing by reference can be done by prefixing the type with the de-reference operator. This type is only available in function parameter declaration. To call a function with this type, a pointer to the desired variable must be given. - -Examples: - - # define int - ;int i - - # pointer to i - ;~int p = ~i - - # set i using p - ;`p = 1 - - # a function taking a pass by reference - /; add_two (`int i) - i += 2 - ;/ - - # calling add_two in two different ways - ;add_two(p) - ;add_two(~i) - - # i is now 5 - -### Casting Types - -Casting between types uses the standard input and output enclosing `()` and `[]` in conjunction. Place a value in the input enclosing characters and a type to output in the output enclosing characters to cast one type to another (`( )[ ]`). - -Examples: - - # define an int and a float - ;int i = 10 - ;float f = 11.5 - - # define a void pointer and set it to reference i - ;~void v = ~i - - # define an int pointer and cast the void pointer to initialize it - ;~int p = (v)[~int] - - # cast the float to an int and set the value of i - ;`p = (f)[int] - -### Defining Types - -In TNSL, types may be defined by using the `struct` keyword. Struct must be used in conjunction with a user defined name and a set of members enclosed in `{}`. Instances of struct types may be larger than their members if not declared `raw` due to type information and extension. Certain restrictions must be applied to `raw` types. These restrictions may be found in Appendix C. - -Types may extend other types and interfaces with some caveats. Raw structs may not extend other structs, but may extend interfaces. Non-raw structs may not extend raw structs. If extending two or more structs, they may not have any conflicting member names. - -Methods may be added to a struct with the `method` block. Immediately following `method` must be the user defined name of the struct. - -Methods may use the `override` or `operator` keywords in function definition. `override` must be used for functions which are named and typed equivalently to extended classes' methods. `operator` allows types to use operators as methods, the keyword must immediately be followed by the operator to overload, and must only have up to one input depending on weather the operator is binary or not. - -Methods may access the special keywords `self` and `super`. `self` is a reference to the instance of the struct that the function was called on. `super` is a reference to any structs or interfaces extended by the struct. If there is only one extended type, it references the methods of that type. Otherwise, it is an array of such objects. It may be called to call the equivalent method on the extended type. `super` may also be used in the member set to position the extended types' members in relation to the new struct's members. - -Examples: - - # normal struct - ; struct box { - float - x, - y, - z - } - - # method block - /; method box - - /; area [float] - return self.x * self.y * self.z - ;/ - ;/ - -### Interfaces - -Interfaces are defined using the `interface` keyword. Interfaces have methods but no struct or members to accompany them. Instances of interfaces may not be created. Methods defined by interfaces must be overridden unless marked in the interface. Such marked methods may call on other methods, but may not use any members as interfaces have none. - -Example: - - /; interface shape - - /; area [float] ;/ - - # this method does not need to be overridden - /; override area_sq [float] - ;float a = self.area() - ;return a*a - ;/ - ;/ - - ;struct box extends shape { - float - x, - y, - z - } - - /; method box - - /; override area [float] - ;return x*y*z - ;/ - ;/ - -### Enums - -Enums are defined using the `enum` keyword. An enum represents a set of possible states, and requires a single output type which can be compared. - -Enums may be defined in conjunction with the `raw` keyword. When defined in this way, each state is mutually exclusive and must be represented by a single bit of a uint type. Raw enums may be thought of more akin to bit-masks. - -Examples: - - # non-raw enums must define each value - ; enum color [int] { - # In standard styling, these use UPPER_SNAKE_CASE - RED = 1, - BLUE = 2, - ... - YELLOW = 12 - } - - # raw enums may not define any value - ; raw enum object_material { - WOOD, - METAL, - GLASS, - PLASTIC, - ... - ROCK - } - -## Section 5 - Operators - -An exhaustive list of operators can be found in Appendix A - -### Operator Precedence - -Operator precedence is as follows (from greatest to least): - - Pointer operators (p0): - - ~ - address of - - ` - de-reference - - - Access operator (p1): - - . - get/access - - - Increment/de-increment (p2): - - ++ - increment - - -- - de-increment - - - Multiplication/division (p3): - - * - multiply - - / - divide - - - Addition and subtraction (p4): - - + - addition - - - - subtraction - - - Modulus (p5): - - % - modulus - - - Bitwise operators (p6): - - & - and - - | - nor - - ^ - xor - - << - shift left - - >> - shift right - - !& - nand - - !| - nor - - !^ - xand - - ! - not (bitwise or boolean) - - - Boolean operators (p7): - - && - boolean and - - || - boolean or - - == - boolean eq - - > - greater than - - < - less than - - !&& - boolean nand - - !|| - boolean nor - - !== - boolean neq - - !> - boolean not greater than - - !< - boolean not less than - - >== - boolean greater than or equal to - - <== - boolean less than or equal to - -## Section 6 - `raw` and `asm` - -### The `raw` Keyword - -The `raw` keyword can be used in four different scenarios, and each has a different meaning. - -1. The `raw` keyword can be used in function definitions. These effects were discussed in section 2.2. - -2. The `raw` keyword may be used in conjunction with the `return` keyword, but only inside of raw functions. This causes an instant return regardless of stack or register state. It is recommended to clean up function and provide return types before using this. - -3. The `raw` keyword may be used with the `struct` keyword to create a raw struct. Raw structs can not contain user defined types or generics. Raw types encode no type information and may not be extended. Raw structs, unlike static or dynamic structs, are only as wide their members. - - Static and dynamic structs contain a small amount of information pertaining to their actual type and generics so may be larger than only their members. - - In addition, since static and dynamic structs may be extended, they may not be the initially defined type and may be larger, further complicating matters. - -4. The `raw` keyword may be used with the `enum` keyword to create a raw enum. Raw enums only have at most one state per bit and may bitwise or and bitwise and to generate a full state. Raw enums are much akin to bit-masks. - -### The `asm` Keyword - -The `asm` keyword may be used in `raw` functions or blocks to produce raw asm code for the assembler. Any valid assembly code may be used, and certain extensions are available such as variable pointer references. - -Syntax: - - ;asm "" - -## Credits - - Copyright 2021 Kyle Gunger - - This file is licensed under the CDDL 1.0 (the License) - and may only be used in accordance with the License. - You should have received a copy of the License with this - software/source code. If you did not, a copy can be found - at the following URL: - - https://opensource.org/licenses/CDDL-1.0 - - THIS SOFTWARE/SOURCE CODE IS PROVIDED "AS IS" WITH NO - WARRANTY, GUARANTEE, OR CLAIM OF FITNESS FOR ANY PURPOSE - EXPRESS OR IMPLIED \ No newline at end of file diff --git a/spec/1.md b/spec/1.md new file mode 100644 index 0000000..47e6834 --- /dev/null +++ b/spec/1.md @@ -0,0 +1,525 @@ +# The Language + +## Section 1 - Files + +### Folder Structure + +Normal TNSL project structure has a root source folder with TNSL files contained within the folder and sub-folders. It is normal for the root folder to represent a single library or binary, although there is no strict rule enforcing this. Standard organization is to place sub-modules in sub-folders. The file name for the module entry point should match the folder name. + +The file representing the compile target is known as the root file, which generally resides in the root source folder. This file will contain a main method, and/or the pre-processor statement `rootfile` to denote the root of a library. If both are present, the compiler will generate an executable by default unless the `--otype` flag is set to `library` or `tlet`. + +### TNSL Files + +TNSL files end with the `.tnsl` extension and may contain the following: +- Comments +- Pre-processor statements +- Modules +- Constant and variable definitions +- Named function blocks +- Struct definitions +- Method and interface blocks + +The following may only occur within named function or method blocks: +- Re-assignment of variables +- Control flow blocks +- Function calls +- Anonymous blocks (Scope blocks) + +## Section 2 - Blocks + +### TNSL Block Notation + +Blocks in tnsl consist of a slash `/` and a character denoting the type of block. The reverse of these symbols end the block. The three types of blocks are comment, pre-processor, and code. Code blocks can be further broken down into modules, functions, control flow, methods, and interfaces. + + Examples of standard block opening and closing characters: + + /# - open comment + #/ - close comment + + /: - open pre-processor + :/ - close pre-processor + + /; - open code + ;/ - close code + +In addition to the standard opening and closing characters, there exist "swivel" character sets to quickly close and open a block type + + ;; - close code, then open code + #; - close comment, open code + ;# - close code, open comment + :: - close pre-processor, open preprocessor + #: - close comment, open pre-processor + :# - close pre-processor, open comment + +### Modules + +Modules are akin to namespaces in C++ + +They hold a group of related modules, functions, structs, and variables. These named definitions may be used by other projects if the `export` keyword is used in conjunction with the `module` keywor; otherwise, the names are not exported into the file's symbol table. + +### Module definition example: + +*File a.tnsl (project a)* + + /; export module pubmod + /; module hidden + # Can access all from pubmod, and pubmod.hidden + ;/ + # Can access all from pubmod, and pubmod.hidden + ;/ + # Can access all from pubmod, and pubmod.hidden + +*File aa.tnsl (project a)* + + /; my_function_a + # Can access all from pubmod, and pubmod.hidden + ;/ + # Can access all from pubmod, and pubmod.hidden + +*File b.tnsl (project b)* + + /; my_function + # Can access all from pubmod, but not pubmod.hidden + ;/ + # Can access all from pubmod, but not pubmod.hidden + +### Functions + +TNSL functions are code blocks whose definition contains none of the following: control flow keywords, the module keyword, the method keyword. TNSL functions are called methods if they are contained within a method block. TNSL methods may only be called with relation to the user defined type they are linked to. If a TNSL function has no user defined name, it is anonymous. Anonymous functions can be stored as void type variables or called immediately. If an anonymous function is not stored, it is interpreted as inline and called immediately (this is known as a scope block). + +Function blocks may have inputs and/or outputs. Inputs are enclosed by `()` and outputs are enclosed by `[]` + +Input lists must begin with a type and conclude with at least one named parameter. If no type is given after a comma, it is assumed that the previous type carries over. + +Output lists consist of a comma seperated list of types. + +Either of these may be omitted for no input and/or output. + +TNSL functions may have their call stack modified by the `raw` and/or `inline` keywords. If the `inline` keyword is placed before the function declaration, the function will still be exported (if it is being exported), but any time it is used in the project's code, it will be optimized as if in-line. + +The use of the `raw` keyword has several effects: the function will have no generated assembly preamble, the function will allow `raw return` statements, the function will not be optimized, and the function will allow `asm` statements. Any function may be labeled `raw`, even `main` and anonymous functions. + +Functions *may* be overloaded (that is, two functions may share names but have differing input type lists). Overloaded functions *may not* share the same inputs and differing outputs, but *may* have both differing inputs and differing outputs. + +Examples: + + # simple function with no inputs or outputs named "my_function" + /; my_function + + ;/ + + # function with inputs and outputs + /; my_second_function ( input1, input2 ) [ , , ... , ] + + ;/ + + # funtion with a scope block + /; my_third_function + + # a scope block + /; + + ;/ + ;/ + +### Control Flow Blocks + +Control flow blocks are code blocks whose definitions contain the keywords if, else, loop, match, case, or default. + +For if, else, loop, and match any inputs and/or outputs are a semicolon-separated list of statements. For case or default, only inputs are accepted in the form of a single value. Any variables defined in these inputs or outputs are scoped to the block only. Control flow blocks may not actually output any values; instead, any statements in the output are evaluated when the block ends, weather it loops or not. + +Examples: + + # simple if block + /; if ( ) + + ;/ + + # if block with else and else if + /; if ( ; ; ... ; ) + + ;; else if ( ) + + ;; else + + ;/ + + # loop block + /; loop ( ; ... ; ) + [ ] + + + ;/ + + # match block + /; match ( ; ... ; ) + + /; case + + ;; case + + # Continue here would fall through to default + ;; default + + ;/ + ;/ + +## Section 3 - Statements + +### TNSL Statement Notation + +There are three types of tnsl statements: code, pre-processor, and comment. Code statements begin with `;` and end at the next statement. Pre-processor statements begin with `:` and end at the next statement. Comment statements (line comments) begin with `#` and end at the next new line. After a line comment ends, the previous statement resumes. + +### Variable Declaration + +Declaring a variable is done by referencing a type and then giving a list of names for the new variables. Optionally, a list of values may be given to initialize the new variables. + +Variables may be augmented by the following keywords: `const`, `volatile`, and/or `static`. + +Declaring a variable as `const` means that it is a constant and must be immediately initialized. A constant may not be re-assigned a value. + +Declaring a variable as `volatile` means that the compiler will not attempt to optimize operations performed on it. + +Declaring a variable `static` means that the value will be kept between function calls. Static variables may create race conditions when paired with threads. + +Examples: + + # list with initialization + ;int a, b = 0, 1 + + # single without initialization + ;int c + + # list with partial initialization + ;int d, e = 0 # d is defined, but e is not + +## Section 4 - Types + +An exhaustive list of built-in types can be found in Appendix B. + +### The `void` Type + +The `void` type represents one of two things: an unknown data type, or a function. When the void type is paired with input and output parameters `void( )[ ]` it represents a function. When it is not paired with these things it represents an unknown data type. + +Pure `void` types can not be created. Function types are *always* references to the function, more like pointers than data holders. Otherwise, void types must be created as pure pointers. In this case, they are in a sense "un-typed" pointers which do not know the length of the object they are pointing at, only the address. + +Examples: + + # simple function + /; func_1 + ;/ + + # void example func + /; func_2 + + # create a void type and assign it func_1's value + ;void()[] func_ref = func_1 + + # call func_1 using func_ref + ;func_ref() + ;/ + +More examples of pointer voids are available in the pointers section of this document. + +### Arrays + +In memory, arrays store their length as a uint, then immediately follow with the contents of the array. This way, all arrays can be checked for length with the `len` operator. + +Arrays are created by prefixing a type with `{ <# of elements> }` or simply `{}` so long as the array is immediately initialized. One can similarly access an element of an array by suffixing the variable name with `{ }`. + +When initializing or assigning a new value to an entire array, use `{}` to encase a list of values. + +The length of the array can be gotten by `len ` + +Examples: + + # create an array of five integers + ;{5}int i + + # assign values to the array + ;i{0} = 0 + ;i{1} = 2 + ;i{2} = 0 + ;i{3} = 2 + ;i{4} = 1 + + # store the length of the array + ;uint array_length = len i + + # create an initialized array with length five + ;{}int j = {1, 2, 3, 4, 5} + + # loop through the array and add them. + /; loop (int k = 0; k < array_length) [k++] + + ;i{k} += j{k} + ;/ + + +### Pointers + +Pointer types are created using the `~` (pointer to) operator. This operator serves as both part of the type, and as a way to get a pointer from a type. To de-reference a pointer into it's base type, use the `` ` `` (de-reference) operator. + +Passing by reference can be done by prefixing the type with the de-reference operator. This type is only available in function parameter declaration. To call a function with this type, a pointer to the desired variable must be given. + +Examples: + + # define int + ;int i + + # pointer to i + ;~int p = ~i + + # set i using p + ;`p = 1 + + # a function taking a pass by reference + /; add_two (`int i) + i += 2 + ;/ + + # calling add_two in two different ways + ;add_two(p) + ;add_two(~i) + + # i is now 5 + +### Casting Types + +Casting between types uses the standard input and output enclosing `()` and `[]` in conjunction. Place a value in the input enclosing characters and a type to output in the output enclosing characters to cast one type to another (`( )[ ]`). + +Examples: + + # define an int and a float + ;int i = 10 + ;float f = 11.5 + + # define a void pointer and set it to reference i + ;~void v = ~i + + # define an int pointer and cast the void pointer to initialize it + ;~int p = (v)[~int] + + # cast the float to an int and set the value of i + ;`p = (f)[int] + +### Defining Types + +In TNSL, types may be defined by using the `struct` keyword. Struct must be used in conjunction with a user defined name and a set of members enclosed in `{}`. Instances of struct types may be larger than their members if not declared `raw` due to type information and extension. Certain restrictions must be applied to `raw` types. These restrictions may be found in Appendix C. + +Types may extend other types and interfaces with some caveats. Raw structs may not extend other structs, but may extend interfaces. Non-raw structs may not extend raw structs. If extending two or more structs, they may not have any conflicting member names. + +Methods may be added to a struct with the `method` block. Immediately following `method` must be the user defined name of the struct. + +Methods may use the `override` or `operator` keywords in function definition. `override` must be used for functions which are named and typed equivalently to extended classes' methods. `operator` allows types to use operators as methods, the keyword must immediately be followed by the operator to overload, and must only have up to one input depending on weather the operator is binary or not. + +Methods may access the special keywords `self` and `super`. `self` is a reference to the instance of the struct that the function was called on. `super` is a reference to any structs or interfaces extended by the struct. If there is only one extended type, it references the methods of that type. Otherwise, it is an array of such objects. It may be called to call the equivalent method on the extended type. `super` may also be used in the member set to position the extended types' members in relation to the new struct's members. + +Examples: + + # normal struct + ; struct box { + float + x, + y, + z + } + + # method block + /; method box + + /; area [float] + return self.x * self.y * self.z + ;/ + ;/ + +### Interfaces + +Interfaces are defined using the `interface` keyword. Interfaces have methods but no struct or members to accompany them. Instances of interfaces may not be created. Methods defined by interfaces must be overridden unless marked in the interface. Such marked methods may call on other methods, but may not use any members as interfaces have none. + +Example: + + /; interface shape + + /; area [float] ;/ + + # this method does not need to be overridden + /; override area_sq [float] + ;float a = self.area() + ;return a*a + ;/ + ;/ + + ;struct box extends shape { + float + x, + y, + z + } + + /; method box + + /; override area [float] + ;return x*y*z + ;/ + ;/ + +### Enums + +Enums are defined using the `enum` keyword. An enum represents a set of possible states, and requires a single output type which can be compared. + +Enums may be defined in conjunction with the `raw` keyword. When defined in this way, each state is mutually exclusive and must be represented by a single bit of a uint type. Raw enums may be thought of more akin to bit-masks. + +Examples: + + # non-raw enums must define each value + ; enum color [int] { + # In standard styling, these use UPPER_SNAKE_CASE + RED = 1, + BLUE = 2, + ... + YELLOW = 12 + } + + # raw enums may not define any value + ; raw enum object_material { + WOOD, + METAL, + GLASS, + PLASTIC, + ... + ROCK + } + +## Section 5 - Operators + +An exhaustive list of operators can be found in Appendix A + +### Operator Precedence + +Operator precedence is as follows (from greatest to least): + + Pointer operators (p0): + + ~ - address of + + ` - de-reference + + + Access operator (p1): + + . - get/access + + + Increment/de-increment (p2): + + ++ - increment + + -- - de-increment + + + Multiplication/division (p3): + + * - multiply + + / - divide + + + Addition and subtraction (p4): + + + - addition + + - - subtraction + + + Modulus (p5): + + % - modulus + + + Bitwise operators (p6): + + & - and + + | - nor + + ^ - xor + + << - shift left + + >> - shift right + + !& - nand + + !| - nor + + !^ - xand + + ! - not (bitwise or boolean) + + + Boolean operators (p7): + + && - boolean and + + || - boolean or + + == - boolean eq + + > - greater than + + < - less than + + !&& - boolean nand + + !|| - boolean nor + + !== - boolean neq + + !> - boolean not greater than + + !< - boolean not less than + + >== - boolean greater than or equal to + + <== - boolean less than or equal to + +## Section 6 - `raw` and `asm` + +### The `raw` Keyword + +The `raw` keyword can be used in four different scenarios, and each has a different meaning. + +1. The `raw` keyword can be used in function definitions. These effects were discussed in section 2.2. + +2. The `raw` keyword may be used in conjunction with the `return` keyword, but only inside of raw functions. This causes an instant return regardless of stack or register state. It is recommended to clean up function and provide return types before using this. + +3. The `raw` keyword may be used with the `struct` keyword to create a raw struct. Raw structs can not contain user defined types or generics. Raw types encode no type information and may not be extended. Raw structs, unlike static or dynamic structs, are only as wide their members. + - Static and dynamic structs contain a small amount of information pertaining to their actual type and generics so may be larger than only their members. + - In addition, since static and dynamic structs may be extended, they may not be the initially defined type and may be larger, further complicating matters. + +4. The `raw` keyword may be used with the `enum` keyword to create a raw enum. Raw enums only have at most one state per bit and may bitwise or and bitwise and to generate a full state. Raw enums are much akin to bit-masks. + +### The `asm` Keyword + +The `asm` keyword may be used in `raw` functions or blocks to produce raw asm code for the assembler. Any valid assembly code may be used, and certain extensions are available such as variable pointer references. + +Syntax: + + ;asm "" + +## Credits + + Copyright 2021 Kyle Gunger + + This file is licensed under the CDDL 1.0 (the License) + and may only be used in accordance with the License. + You should have received a copy of the License with this + software/source code. If you did not, a copy can be found + at the following URL: + + https://opensource.org/licenses/CDDL-1.0 + + THIS SOFTWARE/SOURCE CODE IS PROVIDED "AS IS" WITH NO + WARRANTY, GUARANTEE, OR CLAIM OF FITNESS FOR ANY PURPOSE + EXPRESS OR IMPLIED \ No newline at end of file diff --git a/spec/2 - related.md b/spec/2 - related.md deleted file mode 100644 index c398309..0000000 --- a/spec/2 - related.md +++ /dev/null @@ -1,111 +0,0 @@ -# Related Features - -## Section 1 - Style Guide - -This style guide is primarially for anyone working on tnsl-lang and to a baseline good practice. However, different programmers and groups will feel differently, the real recommendation is to keep your project consistant. Pick and choose what you need such that it fits your needs and everyone is on board, just keep it consistant. - -This section will probably feel less formal than the others simply due to how subjective things are. - -### Tabs or Spaces - -You will for the most part see tabs being used over spaces in tnsl-lang. This is not to keep file sizes down, but instead so that anyone can tweak how the files look to fit their asthetic best without affecting anyone else. Adjust tab sizing on your machine and it won't change it on mine. - -### Naming Convention - -NOTE: Remember that naming convention is no substitute for readability. If your names don't make sense, neither does your code. x, y, and z may be fine, but that doesn't help anyone else figure out what you're using them for. If a particular implementation *does* use variables that are hard to name, feel free to use letter identifiers, but add some short comments to explain what you're doing and how (see comments for more info). - -- UPPER_SNAKE_CASE for constants and enum values - -- lower_snake_case for functions, and methods - -- UpperCamelCase or flatcase for enums, types, and interfaces - - it is recommended that interfaces start with the letter i - -- lowerCamelCase (hungarian notation acceptable) for type/struct members - -- flatcase for modules - -## Comments - -Comments should strive to tell programmers what a function does or what a struct's member is for rather than how it goes about doing/generating said thing. Particularly obtuse implimentations are free to use comments to explain their code. - -Comment blocks starting with an extra number sign `/##` are documentation comments. If they are at the top of the file, they provide either info about the file or license information. If they appear directly before (or joined to using `#;`) a function or method they explain what the function or method does. - -## Directory Structure - -`src` will be the name of the root source files/folders, `build` will be the name of the outputed files/folders. - -The name of the *main* root file (there may be multiple root files) will be the project folder name followed by .tnsl (example: project tnslc's root file is `src/tnslc.tnsl`). - -Sub-modules shall be contained in their own folder, and the main entry point to the module will be named the same as that folder followed by .tnsl (example: module `tnsl.alg` in libtnsl has the main entry point for the module `/src/alg/alg.tnsl`). - -## Section 2 - Compiler Options - -An exhaustive list of all compiler options can be found in the spec for tnslc, but these are a general sub-set for working on lower-level projects and language bootstrapping. - -### ISA Options - -The tnslc compiler can output for a variety of backends. These can be set with the `--arch ` option. - -### Pre-processor - -tnslc can preemptively set pre-processor variables using the `--V "VARIABLE=value, VARIABLE2=value2, ..."` option. - -### Standard Library - -Access to the standard library can be disabled (bare metal mode) by using the `--no-libtnsl` flag. Also use this to build the standard library as it will attempt to link improperly otherwise. - -### T-LETs - -What T-LETs exactly are is discussed later. You can have tnslc produce them by passing the `--otype tlet` flag. - -## Section 3 - The Pre-Processor - -An exhaustive account of the full pre-processor can be found in the tnslc specification. - -### Including Other Files - -Use the `include` directive to include other code. This can be a library using single quotation marks (example: `:include 'tnslc'`), another file using a path with double quotes (example: `:include "c.tnsl"` reads as `:include "./c.tnsl"`), or a module in a subfolder using expanded syntax (`:include "some_module"` reads as `:include "./some_module/some_module.tnsl"`). - -No header guard is needed, tnslc can pick up on if a file has already been included in the project. - -Cyclic dependency for files is fine. Cyclic dependency for structs is not. - -## Section 4 - libtnsl - -An exhaustive list of all features included in the standard libtnsl is provided in the libtnsl spec. This is a short list of minimum functions a libtnsl must provide to make full use of the tnsl programming language. - -### Method and type resolution for non-raw types - -**TBD - this sub-section is under construction** - -The type `tnsl.reflect.type` must exist and must be a raw struct. This is for storing type information. - -The module `tnsl.reflect` must provide the following functions/methods: - -- `type._get_member_ [tnsl.reflect.library]` -- `tnsl.reflect._is (type check, base) [bool]` - -### Vector types - -The type `tnsl.vector.vector` must exist. This is the generic simd/vector type and is referenced by `vect`. - -## Section 5 - TNSL-Lang Export Trees (T-LETs) - -TNSL doesn't use header files, and downloading full source code for every library being referenced would be a pain. This is where T-LETs come in. T-LETs contain a tree of all exported modules, functions, types, methods, and doc comments from a project. They are more compact and are simply named `.tlet`. - -## Credits - - Copyright 2021 Kyle Gunger - - This file is licensed under the CDDL 1.0 (the License) - and may only be used in accordance with the License. - You should have received a copy of the License with this - software/source code. If you did not, a copy can be found - at the following URL: - - https://opensource.org/licenses/CDDL-1.0 - - THIS SOFTWARE/SOURCE CODE IS PROVIDED "AS IS" WITH NO - WARRANTY, GUARANTEE, OR CLAIM OF FITNESS FOR ANY PURPOSE - EXPRESS OR IMPLIED diff --git a/spec/2.md b/spec/2.md new file mode 100644 index 0000000..c398309 --- /dev/null +++ b/spec/2.md @@ -0,0 +1,111 @@ +# Related Features + +## Section 1 - Style Guide + +This style guide is primarially for anyone working on tnsl-lang and to a baseline good practice. However, different programmers and groups will feel differently, the real recommendation is to keep your project consistant. Pick and choose what you need such that it fits your needs and everyone is on board, just keep it consistant. + +This section will probably feel less formal than the others simply due to how subjective things are. + +### Tabs or Spaces + +You will for the most part see tabs being used over spaces in tnsl-lang. This is not to keep file sizes down, but instead so that anyone can tweak how the files look to fit their asthetic best without affecting anyone else. Adjust tab sizing on your machine and it won't change it on mine. + +### Naming Convention + +NOTE: Remember that naming convention is no substitute for readability. If your names don't make sense, neither does your code. x, y, and z may be fine, but that doesn't help anyone else figure out what you're using them for. If a particular implementation *does* use variables that are hard to name, feel free to use letter identifiers, but add some short comments to explain what you're doing and how (see comments for more info). + +- UPPER_SNAKE_CASE for constants and enum values + +- lower_snake_case for functions, and methods + +- UpperCamelCase or flatcase for enums, types, and interfaces + - it is recommended that interfaces start with the letter i + +- lowerCamelCase (hungarian notation acceptable) for type/struct members + +- flatcase for modules + +## Comments + +Comments should strive to tell programmers what a function does or what a struct's member is for rather than how it goes about doing/generating said thing. Particularly obtuse implimentations are free to use comments to explain their code. + +Comment blocks starting with an extra number sign `/##` are documentation comments. If they are at the top of the file, they provide either info about the file or license information. If they appear directly before (or joined to using `#;`) a function or method they explain what the function or method does. + +## Directory Structure + +`src` will be the name of the root source files/folders, `build` will be the name of the outputed files/folders. + +The name of the *main* root file (there may be multiple root files) will be the project folder name followed by .tnsl (example: project tnslc's root file is `src/tnslc.tnsl`). + +Sub-modules shall be contained in their own folder, and the main entry point to the module will be named the same as that folder followed by .tnsl (example: module `tnsl.alg` in libtnsl has the main entry point for the module `/src/alg/alg.tnsl`). + +## Section 2 - Compiler Options + +An exhaustive list of all compiler options can be found in the spec for tnslc, but these are a general sub-set for working on lower-level projects and language bootstrapping. + +### ISA Options + +The tnslc compiler can output for a variety of backends. These can be set with the `--arch ` option. + +### Pre-processor + +tnslc can preemptively set pre-processor variables using the `--V "VARIABLE=value, VARIABLE2=value2, ..."` option. + +### Standard Library + +Access to the standard library can be disabled (bare metal mode) by using the `--no-libtnsl` flag. Also use this to build the standard library as it will attempt to link improperly otherwise. + +### T-LETs + +What T-LETs exactly are is discussed later. You can have tnslc produce them by passing the `--otype tlet` flag. + +## Section 3 - The Pre-Processor + +An exhaustive account of the full pre-processor can be found in the tnslc specification. + +### Including Other Files + +Use the `include` directive to include other code. This can be a library using single quotation marks (example: `:include 'tnslc'`), another file using a path with double quotes (example: `:include "c.tnsl"` reads as `:include "./c.tnsl"`), or a module in a subfolder using expanded syntax (`:include "some_module"` reads as `:include "./some_module/some_module.tnsl"`). + +No header guard is needed, tnslc can pick up on if a file has already been included in the project. + +Cyclic dependency for files is fine. Cyclic dependency for structs is not. + +## Section 4 - libtnsl + +An exhaustive list of all features included in the standard libtnsl is provided in the libtnsl spec. This is a short list of minimum functions a libtnsl must provide to make full use of the tnsl programming language. + +### Method and type resolution for non-raw types + +**TBD - this sub-section is under construction** + +The type `tnsl.reflect.type` must exist and must be a raw struct. This is for storing type information. + +The module `tnsl.reflect` must provide the following functions/methods: + +- `type._get_member_ [tnsl.reflect.library]` +- `tnsl.reflect._is (type check, base) [bool]` + +### Vector types + +The type `tnsl.vector.vector` must exist. This is the generic simd/vector type and is referenced by `vect`. + +## Section 5 - TNSL-Lang Export Trees (T-LETs) + +TNSL doesn't use header files, and downloading full source code for every library being referenced would be a pain. This is where T-LETs come in. T-LETs contain a tree of all exported modules, functions, types, methods, and doc comments from a project. They are more compact and are simply named `.tlet`. + +## Credits + + Copyright 2021 Kyle Gunger + + This file is licensed under the CDDL 1.0 (the License) + and may only be used in accordance with the License. + You should have received a copy of the License with this + software/source code. If you did not, a copy can be found + at the following URL: + + https://opensource.org/licenses/CDDL-1.0 + + THIS SOFTWARE/SOURCE CODE IS PROVIDED "AS IS" WITH NO + WARRANTY, GUARANTEE, OR CLAIM OF FITNESS FOR ANY PURPOSE + EXPRESS OR IMPLIED diff --git a/spec/3 - abi.md b/spec/3 - abi.md deleted file mode 100644 index 5ea5c15..0000000 --- a/spec/3 - abi.md +++ /dev/null @@ -1,17 +0,0 @@ -# The TNSL Calling ABI - -## Credits - - Copyright 2021 Kyle Gunger - - This file is licensed under the CDDL 1.0 (the License) - and may only be used in accordance with the License. - You should have received a copy of the License with this - software/source code. If you did not, a copy can be found - at the following URL: - - https://opensource.org/licenses/CDDL-1.0 - - THIS SOFTWARE/SOURCE CODE IS PROVIDED "AS IS" WITH NO - WARRANTY, GUARANTEE, OR CLAIM OF FITNESS FOR ANY PURPOSE - EXPRESS OR IMPLIED \ No newline at end of file diff --git a/spec/3.md b/spec/3.md new file mode 100644 index 0000000..5ea5c15 --- /dev/null +++ b/spec/3.md @@ -0,0 +1,17 @@ +# The TNSL Calling ABI + +## Credits + + Copyright 2021 Kyle Gunger + + This file is licensed under the CDDL 1.0 (the License) + and may only be used in accordance with the License. + You should have received a copy of the License with this + software/source code. If you did not, a copy can be found + at the following URL: + + https://opensource.org/licenses/CDDL-1.0 + + THIS SOFTWARE/SOURCE CODE IS PROVIDED "AS IS" WITH NO + WARRANTY, GUARANTEE, OR CLAIM OF FITNESS FOR ANY PURPOSE + EXPRESS OR IMPLIED \ No newline at end of file diff --git a/spec/4 - fip.md b/spec/4 - fip.md deleted file mode 100644 index c5a0259..0000000 --- a/spec/4 - fip.md +++ /dev/null @@ -1,63 +0,0 @@ -# Features in Position - -To use higher level features in TNSL, an implimentation of libtnsl must be in place with a minimum set of features. This document outlines what concepts are and are not considered "higher level". This document also covers what the minimum set of features are for a given implimentation of libtnsl. Finally, this document covers how to call between TNSL and other programming languages. - -## Section 1 - Bare Metal - -## Section 2 - libtnsl and Types - -`libtnsl` has the authority to define how types are stored in memory (to some extent) and how method resolution works on static and dynamic structs. `libtnsl` *must* provide certain methods for some language features to be available. These functions, and their uses are now listed. A comprehensive list of language keywords can be found in Appendix B. - -### 2.0 - nullptr - -`tnsl._null` *must* be defined as a universal null pointer value. **No type except pointers may be `null`**, but pointers *must* have a null value to distinguish if they point to a meaningful position in memory. - -### 2.1 - The libtnsl Type Extension - -`tnsl.reflect._type` *must* be defined as a raw struct which contains minimum information for type identification. This information is stored with every static or dynamic struct so that programs can reflect type information. - -`tnsl.reflect._member` *should* be defined as a raw struct which contains minimum information for member variable identification within a type. The information need not be stored with every member variable, but should be stored somewhere such that the `tnsl.reflect._get` method can make use of it. - -`tnsl.reflect._method` *must* be defined as a raw struct which contains minimum information for method identification within a type. The information need not be stored with every member function, but should be stored somewhere such that the `tnsl.reflect._call` method can make use of it. - -`tnsl.reflect._is` *must* be defined as a function taking two parameters of type `tnsl.reflect._type` and returning a single `bool` as output. This function is called when the `is` operator is envoked. - -`tnsl.reflect._get` *should* be defined as a function taking three parameters. The first parameter will be of type `tnsl.reflect._type`, the second parameter will be of type `~void`, and the third parameter will be of type `tnsl.reflect._member`. The function will return a single `~void` as output. - -In the parameters, the first relates to the type of the struct given, or at least how the callee views the struct. The second is a pointer to the struct itself. The third is the requested member to get. The `~void` returned must point to the requested value. - -`tnsl.reflect._call` *must* be defined as a function taking four parameters. The first parameter will be of type `tnsl.reflect._type`, the second parameter will be of type `~void`, the third parameter will be of type `tnsl.reflect._method`, and the fourth parameter will be of type `~void`. The function will return a single `~void` as output. - -In the parameters, the first relates to the type of the struct given, or at least how the callee views the struct. The second is a pointer to the struct itself. The third is the requested method to call. The fourth is a pointer to the parameters for the method. The `~void` returned must point to the return value of the method. - -### 2.2 - Memory allocation and de-allocation - -`tnsl.algo._alloc` *must* be defined as a function taking a single parameter of type `uint` as the number of bytes to allocate and returning a single `~void` as the pointer to the allocated memory. The memory must be allocated from the heap. - -`tnsl.algo._salloc` *should* be defined as a function taking a single parameter of type `uint` as the number of bytes to allocate and returning a single `~void` as the pointer to the allocated memory. The memory must be allocated from the stack. - -`tnsl.algo._dealloc` *must* be defined as a function taking a single parameter of type `~void` as the pointer to a chunk of allocated memory. The function should deallocate the memory. - -### 2.3 - Expanded Types Extension - -`tnsl.box._vect` *must* be a raw struct which vector or simd instructions can be preformed on. - -`tnsl.box._string` *must* be a raw struct which stores a string of text. This text may be ASCII or Unicode, and should be stored as `charp` values internally. - -## Section 3 - Cross calling C - -### Credits - - Copyright 2021 Kyle Gunger - - This file is licensed under the CDDL 1.0 (the License) - and may only be used in accordance with the License. - You should have received a copy of the License with this - software/source code. If you did not, a copy can be found - at the following URL: - - https://opensource.org/licenses/CDDL-1.0 - - THIS SOFTWARE/SOURCE CODE IS PROVIDED "AS IS" WITH NO - WARRANTY, GUARANTEE, OR CLAIM OF FITNESS FOR ANY PURPOSE - EXPRESS OR IMPLIED \ No newline at end of file diff --git a/spec/4.md b/spec/4.md new file mode 100644 index 0000000..c5a0259 --- /dev/null +++ b/spec/4.md @@ -0,0 +1,63 @@ +# Features in Position + +To use higher level features in TNSL, an implimentation of libtnsl must be in place with a minimum set of features. This document outlines what concepts are and are not considered "higher level". This document also covers what the minimum set of features are for a given implimentation of libtnsl. Finally, this document covers how to call between TNSL and other programming languages. + +## Section 1 - Bare Metal + +## Section 2 - libtnsl and Types + +`libtnsl` has the authority to define how types are stored in memory (to some extent) and how method resolution works on static and dynamic structs. `libtnsl` *must* provide certain methods for some language features to be available. These functions, and their uses are now listed. A comprehensive list of language keywords can be found in Appendix B. + +### 2.0 - nullptr + +`tnsl._null` *must* be defined as a universal null pointer value. **No type except pointers may be `null`**, but pointers *must* have a null value to distinguish if they point to a meaningful position in memory. + +### 2.1 - The libtnsl Type Extension + +`tnsl.reflect._type` *must* be defined as a raw struct which contains minimum information for type identification. This information is stored with every static or dynamic struct so that programs can reflect type information. + +`tnsl.reflect._member` *should* be defined as a raw struct which contains minimum information for member variable identification within a type. The information need not be stored with every member variable, but should be stored somewhere such that the `tnsl.reflect._get` method can make use of it. + +`tnsl.reflect._method` *must* be defined as a raw struct which contains minimum information for method identification within a type. The information need not be stored with every member function, but should be stored somewhere such that the `tnsl.reflect._call` method can make use of it. + +`tnsl.reflect._is` *must* be defined as a function taking two parameters of type `tnsl.reflect._type` and returning a single `bool` as output. This function is called when the `is` operator is envoked. + +`tnsl.reflect._get` *should* be defined as a function taking three parameters. The first parameter will be of type `tnsl.reflect._type`, the second parameter will be of type `~void`, and the third parameter will be of type `tnsl.reflect._member`. The function will return a single `~void` as output. + +In the parameters, the first relates to the type of the struct given, or at least how the callee views the struct. The second is a pointer to the struct itself. The third is the requested member to get. The `~void` returned must point to the requested value. + +`tnsl.reflect._call` *must* be defined as a function taking four parameters. The first parameter will be of type `tnsl.reflect._type`, the second parameter will be of type `~void`, the third parameter will be of type `tnsl.reflect._method`, and the fourth parameter will be of type `~void`. The function will return a single `~void` as output. + +In the parameters, the first relates to the type of the struct given, or at least how the callee views the struct. The second is a pointer to the struct itself. The third is the requested method to call. The fourth is a pointer to the parameters for the method. The `~void` returned must point to the return value of the method. + +### 2.2 - Memory allocation and de-allocation + +`tnsl.algo._alloc` *must* be defined as a function taking a single parameter of type `uint` as the number of bytes to allocate and returning a single `~void` as the pointer to the allocated memory. The memory must be allocated from the heap. + +`tnsl.algo._salloc` *should* be defined as a function taking a single parameter of type `uint` as the number of bytes to allocate and returning a single `~void` as the pointer to the allocated memory. The memory must be allocated from the stack. + +`tnsl.algo._dealloc` *must* be defined as a function taking a single parameter of type `~void` as the pointer to a chunk of allocated memory. The function should deallocate the memory. + +### 2.3 - Expanded Types Extension + +`tnsl.box._vect` *must* be a raw struct which vector or simd instructions can be preformed on. + +`tnsl.box._string` *must* be a raw struct which stores a string of text. This text may be ASCII or Unicode, and should be stored as `charp` values internally. + +## Section 3 - Cross calling C + +### Credits + + Copyright 2021 Kyle Gunger + + This file is licensed under the CDDL 1.0 (the License) + and may only be used in accordance with the License. + You should have received a copy of the License with this + software/source code. If you did not, a copy can be found + at the following URL: + + https://opensource.org/licenses/CDDL-1.0 + + THIS SOFTWARE/SOURCE CODE IS PROVIDED "AS IS" WITH NO + WARRANTY, GUARANTEE, OR CLAIM OF FITNESS FOR ANY PURPOSE + EXPRESS OR IMPLIED \ No newline at end of file diff --git a/spec/README.md b/spec/README.md index 0e53e68..1517525 100644 --- a/spec/README.md +++ b/spec/README.md @@ -11,7 +11,7 @@ Right now, TNSL isn't a language. But it *could* be. And, really, I think it's ## Chapter Index -1. The Language +1. [The Language](./1.md) - Files - Blocks @@ -20,7 +20,7 @@ Right now, TNSL isn't a language. But it *could* be. And, really, I think it's - Operators - `raw` and `asm` -2. Related features +2. [Related features](./2.md) - Style guide - Compiler Options @@ -28,21 +28,22 @@ Right now, TNSL isn't a language. But it *could* be. And, really, I think it's - libtnsl - TNSL-lang export trees (T-LETs) -3. The TNSL Calling ABI +3. [The TNSL Calling ABI](./3.md) - Differences from C - Exporting C-like Functions - Types and Arrays in Memory -4. Features in Position +4. [Features in Position](./4.md) - Bare Metal - `libtnsl` as it relates to Types - Cross Calling to C -- Appendix A - Reserved Characters -- Appendix B - Reserved Words -- Appendix C - Speed vs the Type System +- [Appendix](./Appendices.md) + - A: Reserved Characters + - B: Reserved Words + - C: Speed vs the Type System ## Credits -- cgit v1.2.3