codeustech/xita

Xita Secure Kernel

xita's Issues

If compares to wrong value

if ... then ... else ... is comparing the wrong registers in assembly. I think it is comparing to second register, rather than top register.

This needs to be tested and fixed immediately.

Build TypeNode in XCSE

Type declarations should be calling the __decl_type function found in the XCSE image.

Parameters must be set correctly; see XCSE Issue #29

Fix Constructor's Size in Memory Node

The constructor's size entry is showing an incorrect number in memory node.

Currently, it is always showing 0 as size. Though it should equal to the number of records. Note that neither of these are correct.

Each time a record is added to the constructor, the size should increase by the size of the record's type expression.

Type Check: Match With

match ... with ... expressions need to be type checked to ensure each resulting functional expression is of the same type expression.

See the following:

match e with
     f1 -> g1
  |  f2 -> g2
  |  f3 -> g3

In other words, g1, g2, and g3 must all be of equivalent type expressions. They do not have to be the same constructor.

Update (06/15/2021): Should this be allowed to work when g1 through g3 are all constrained by the same typeclass, but not the same type?

Accept return value from nested function

Nested functions are being called correctly, the return value is not handled at all.

• If a nested function's return register is not active in the parent function:
  • Parent function should push the return register directly into it's register stack
• If a nested function's return register is active in the parent function:
  • Parent function should push the return register into a new register before restoring active register's value

Type Check: If Then Else

if p then e1 else e2

If ... then ... else ... expressions need to be type checked to meet the following criteria:

• p: Boolean Value
• e1: Type0
• e2: Type0

p must be a boolean value (or castable to boolean). e1 and e2 can be any valid expressions, as long as their types match.

If e1 and e2 are not equivalent types, a type checking error should be thrown to cross-compiling environment.

Store return registers in FunctionNode

Return registers need to be stored in the FunctionNode definitions at the end of the declaration.

Calling functions can then use these return registers in their stack.

Type expressions should change with context

When a function or parameter is used in a valid, more-restrictive context, the node's type expression should reflect the matching type expression.

Each node should start as TYPE_ARBITRARY until a more restrictive type expression is enforced. Each node's type expression should be as generalized as possible for a given circumstance.

Function declarations with no parameters are throwing syntax errors

Allow functions to be declared without any parameters.

Functions have gone through a lot of volatile changes in the past few days. To stabilize the library, functions were reverted to v0.13.3 style-functions. Everything is semantically working but function declarations are now throwing syntax errors if they do not have at least 1 parameter; the parameter doesn't have to be used.

This issue should be found within <xcs/grammar/xcsl.y>

'this' has no Semantic Meaning

this keyword does not actually return the value of the provided memory address as it should with static memory operators.

This functionality needs to be added into the XCSL assembly infrastructure.

Implement Type Aliases

Types need to be able to be 'aliased' or bound as an additional identifier for a predefined type expression.

For example, this binds the generic integer type to identifier "address":
type address = int

Add Optimization Scheme Recognition

XCSL Cross-Compiler needs to be able to shift between optimization schemes using #define ... statements.

At present, the following schemes need to be recongizable:

• -a32i
• -a32f
• -a48sr
• -a64sr

Migrate Constants Buffers to Modules

Constants declarations only work for a single module file right now.

This needs to be changed so that constants declarations will work within any module that imports the declaration.

This should be accomplished by migrating the global constants declaration buffer from buffers.h to modules/structs.h

Functions without Parameters throw Seg. Fault

Function invocations without parameters are throwing a segmentation fault.

Haven't looked into this yet, but it is assumably caused by an illegal memory access in resolve_expression()

Find the code here:
https://github.com/CodeusTech/XCSL-AArch64/blob/master/src/xcs/ident/ident.h#L43

Use printf() to track down location of segmentation fault.

Invocations w/ args are throwing syntax errors

Functional expressions with parameters/arguments are throwing syntax errors.

This is a fairly recent behavior as of v14.1, so refer to a previous working build when going to fix this issue. This will likely fix Issue XCSL-AArch64#1 as well.

The error is suspected to be due to changes in bison++ file in functional declarations

Prevent Overwrite on Param. Load

NOTE:

• This issue continues XCSL Issue #2
• and requires resolution of XCSL Issue #33

When arguments are loaded from calling function's register stack into callee's parameter registers, there needs to be a check that ensures the calling function's active registers' data is not overwritten.

Instead, it should call the data stack's PUSH operation and then POP after conclusion. Alternatively, it can store data temporarily in another CPU register, if there are available registers remaining in the register stack.

Build ConstantNode in XCSE

When a constant is declared, a corresponding ConstantNode may need to be built in the XCS Environment, as well as within the cross-compiler backend.

For this situation, the assembly procedure __decl_const should be called. Before doing so, OS parameters must be set as according to the spec.

For more information, see XCSE Issue #38

Build External Module Stategy

fork() does not work for XCSL's external module building system, because it doesn't save usable identifiers in the importing scope.

Change this fork() system to something that can actually save both files.

Function Declarations use nonexistant branch

Functions are (correctly) branching to __decl_funct in assembly code at beginning of declarations, but there is no matching XCSE declaration function.

This will need to be silenced or implemented before any testing will be correct.

Prevent Register Data Overwrite

NOTE: Find this issue's Prebug here

The Register Stack needs to detect when an active data/neon register is going to be overwritten. In this circumstance, it needs to push the data to the stack temporarily, then pop the register back after nested scope concludes.

Build header assembly on import

The XCS cross compiler should recursively build header files into corresponding assembly files via open "header.xt" keyword.

At present, the compiler recursively reads files, but does not actually build them into intermediary assembly files. This will need to be resolved for many other issues to be resolved.

Build PUSH operation for Data Stack

Other functionalities within the Xita cross-compiler backend need access to a function that can preserve register data by pushing it temporarily to the data stack.

This should first check to see if another CPU register is available, by querying register stack's size() function. By default, there are 28 available general purpose integer registers in an Xita register stack on ARM64 architecture.

If no registers are available in the active register stack, the data should be kept temporarily in static memory. A typical stack structure would probably suffice, but other structures should be considered as well.

Stack operations in AArch64 need to be aligned to 16-bytes and written in store/load pairs; i.e. two general purpose registers are read/written to the stack per transaction. Some control information may be helpful to store with the data, e.g. function scope ID.

Stub Internal Allocator

Outline the source code for XCS's Memory Allocator.

The allocator will provide a could standard function definitions:

• __xcs_alloc
• __xcs_dealloc
• __xcs_realloc

These functions will only ever be called algorithmically, and an interface will not be provided to the user through XCSL or any other means.

Implement Anonymous Tuples

Add syntax and semantics for handling anonymous tuples

Tuples have the following syntax:
let three = 3 ; "three" ; Three
The aforementioned statement returns a single expression, containing three separate components of differing types.

Then each component can be accessed as such:

const Int x = three.{0};;
const String y = three.{1}

Migrate Types Buffers to Modules

Type declarations only work for a single module file right now.

This needs to be changed so that type declarations will work within any module that imports the declaration.

This should be accomplished by migrating the global type declaration buffer from buffers.h to modules/structs.h

Complex Constructors throw Syntax Error

Constructors need to be definable, given type expression as a parameter.

Constructors should accept a capitalized identifier and can optionally have a type expression binding.

Expand NEON Reg. into 2x64, 4x32

AArch64 NEON Registers are 128-Bit vectors -- Sixteen entries of 8-bit.

Currently, only *.s[0] is used (s == 32-bit), so only 32 of the 128 addressable bits are actually being used in the NEON registers. This needs to be changed so the entire register is being used.

This change will create an additional issue where the Serialization Register needs to be expanded. For more detail, see XCSL Issue #39

Handle NEON Registers Arithmetic

XCS cross compiler always assumes it is dealing with a general-purpose register, right now.

This handling should continue for general purpose registers, but the NEON registers have different syntax for access/mutation.

The register stack needs to detect when a neon register is being used and use its syntax rather than General-Purpose syntax.

First parameter is errant

The first parameter is not being saved/read correctly by the cross-compiler. This is certainly happening at time of declaration. Possible that it is happening at time of access, as well; not for sure yet.

At present, the first parameter of each function declaration does absolutely nothing. So, if a function call needs to have two parameters, it actually needs to have three parameters, and basically just throw the first parameter out.

Although ugly, function declarations do produce a correct result if used with this nuance in mind.

Build FunctionNode in XCSE

When functions are declared, a functional node may need to be built in the XCS Environment, as well as within the cross-compiler backend.

For this situation, the assembly procedure __decl_funct should be called. Before doing so, OS parameters must be set as according to the spec.

For more information, see XCSE Issue #39

Protect Registers from Overwrite

Before transitioning into a child functional scope, the parent should ensure the data held in the CPU registers is protected from being overwritten in the Child Scope.

Before making the assembly call:
bl __SCOPE_FUNCTION

• Check parent's active registers against child's active registers
• Push conflicting registers in parent scope to data register until call ends

Develop dealloc, realloc in XCSL

NOTE: These functions are the easy ones to build.

_xcs_dealloc() and _xcs_realloc() should error check the given values as arguments.

They add commands to the compiled assembly file which store expected arguments in corresponding OS parameter registers. (e.g. x1 - x4)

Afterwards, they call assembly functions like so:

bl  __xcs_alloc   ; Allocate
bl  __xcs_dealloc ; Deallocate
bl  __xcs_realloc ; Reallocate

Fix Dynamic Register Sizing

When register names were migrated to new (correct) naming scheme, register size control was broken.

The problematic code can be found in regstack/codes.h.

Currently, it always assumes 32-bit register name for general purpose registers (e.g. w0). Additionally, the NEON registers have no size accessor values provided. Accesses should be sized to best-fit whenever sensible.

Implement Type Parameter Semantics

Types should be able to have parameters for templated structures.

At declaration, the user can assign an identifier to a parameter; then types can be defined at runtime by supplying a type expression as argument.

Expand Serialization Register

AArch64's NEON registers allow XCS to have more integer registers for general-purpose computing.

However, this shift requires that more registers are tracked, so the Serialization register will need to be modified to handle the increase in addressable registers.

The first register that should be repurposed for additional serialization space is v17. Depending on needs, v31 (OS Parameters Register) may also be available.

Migrate Functions Buffers to Modules

Function declarations only work for a single module file right now.

This needs to be changed so that function declarations will work within any module that imports the declaration.

This should be accomplished by migrating the global function declaration buffer from buffers.h to modules/structs.h

Perform Context Shift on Module Import

XCS buffers have been properly reorganized into the new ModuleNode class and there is a global status buffer context for determining place in a Module Tree.

context should be shifted as new modules are imported.

Enumerate Constructors upon Declaration

Each constructor is given an enum value, regardless of whether or not it has a type expression binding.

• This enum value is produced using a global counting variable. (count_struct)
• The constructor is referenced using: count_struct - struct_enum , where struct_enum is derived from parent TypeNode

Develop "Flat" Memory Allocator

Before developing the full-flesh routines, first develop 'flat' allocation. Flat allocation is when each node is allocated one after another in memory space.

This will eventually be changed when a random number generator is implemented in XCSE image.

Accept multiple function return values

NOTE: This issue extends XCSL Issue #14.

When a developer uses the tuple operator, it should signal to function interface to return several values.

This means the register, data type, etc. should be stored for each expression in the resuling tuple.

Develop Memory Allocation Routines

Build definitions for each of the major memory allocation functionalities.

• __xcs_alloc
• __xcs_dealloc
• __xcs_realloc

Serialize Active Registers

Any active Data Registers and Neon Registers need to be encoded into the serialization register upon conclusion of the module.

These are encoded into registers v13-v16. The exact procedure on XCS serialization can be found in the Xita-AArch64 project wiki

Add IEEE Floating-Point Numbers

Use 80-bits from each NEON register for holding IEEE-styled Floating Point Numbers.

Each NEON register should hold two data entries. When one of the data entries is a float, the other entry is restricted to 32-bit types and smaller.

More information on this can be found in the description for the -a32f optimization setting in the XCS Tech Spec, chapter 1.

Error-check Type's `decl_` functions

Declaration functions in XCS's type infrastructure make a lot of unsafe calls.

Each of these functions need to be checked for appropriate boundary conditions and such.

Stub Data Stack

Numerous XCSL features now require use of the temporary data stack.

The data stack needs to be laid out with function stubs. For now, it is sufficient for each function to be = 1.

Ultimately, the Data Stack needs to be a system for pushing data from arbitrary registers into AArch64's local stack.

Fix Register Names in RegStack

Currently, it is printing w0 - w54 as the register names in the register stack, but this is errant behavior.

The proper register names can be found in the XCS Tech Spec, beginning of Chapter 1.

Restructure structs into `<.../ident/types/structs>`

The current definitions for types' data structures are within <xcs/std/structs>, but it would be organizationally better if they were in <xcs/ident/types/structs>

In addition to moving the definitions, TypeNode and ConstructorNode should be reworked completely.

Implement Constructor Casting

Allow users to cast data to a type/constructor by prefacing an expression with a desired constructor.

For example:

Float 10 -- convert integer to float

Primitives need to be Type Checked

The current infrastructure setup works, but it is unsafe and will ultimately lead to bugs. Before then, we need to implement static/dynamic type checking in full.

Records should be stored in TypeNode

Constructors can have 'records', which are the entries that make up a constructor's data structure.

Records each have an identifier and type expression. This information needs to be stored with the owning ConstructorNode in a vector of RecordNode.