I have been doing a lot of under-the-hood refactors recently. The context system for emission has been completely redesigned.
- Previously there was one instance of `IR::Context` that handled all AST & scope specific information to be used in the emission phase
- This got really clunky as features grew and language matured
- Now, there is `EmitCtx` that can created on the fly with the relevant information by the top-level entities, to be used by their children for emission. This makes it possible to do trivial context-switching for emission in a different scope.
- While I have been wanting to do this for long for ergonomic reasons, this mainly paves way for prerun functions (compile-time functions)

EmitCtx instead of IR::Context for maintaining state of emission

I have started working on a register based VM for the language. The design of the foundation of the VM is not finalised, but I have decided to go forward with explicit instructions for each variant of an operation.
For example, 
- `add_i32_reg` for adding i32 in 2 registers
- `add_i32_reg_pre` for adding an i32 in a register with a constant (prerun) value
- `add_i32_pre_reg` for the reverse order of the previous instruction

This is to avoid additional conditions and reduce time for dispatch. And also for reducing bytecode size.

Beginning of the VM project

The entity dependency system is only for top level entities like types, functions... Statements and expressions by nature are handled by their parent entity as the dependencies are known

Completely rehauled the emission system. The previous system to generate LLVM IR was loosely similar to the visitor pattern. This has been rehauled.
- Now, before compilation, the dependencies are properly detected and tracked. The emission phase is now not sequential. If all dependencies are resolved, the entity is created and its contents emitted.
- The compiler takes several turns until no new entities are handled. Meaning that the emission cannot go forward as there are conflicting/convoluted dependencies. Majority of use cases are properly handled, unlike in C & C++
- An entity can have multiple phases of emission. A dependency could be for any of these phases. Entities also have status to indicate whether they are partially or completely created, or whether their children are created or not

Rehauled emission system

Methods can now be conditionally defined. In this example, the `transpose` variation exists for a variant of Matrix only if it is a square matrix (rows == columns)
![Conditional Method Example](image:waj9pnqcvs5nefx)

Conditional methods

I have been recently working on FFI, SIMD vectorized types and other ergonomics and bugfixes
- I made bindings to GLEW, SDL2 and have successfully been able to create windows and draw items on the window using sdl. This was done as an exercise and also as a test project. Several bugs have been caught as part of this and fixed for good. The GLEW interface is about 5000 lines of code and SDL is about 3000
- SIMD vectorized types are now built-in to the language. `vec:[4, i8]` is a fixed vector type, and `vec:[?, 4, i8]` is a scalable vector type. Scalable vector types cannot be allocated and only exist as a value
- Introducing value methods. Methods that operate on the value of the parent type, instead of a reference to it. These methods can be defined only for types that are trivially copyable and trivially movable. This makes it possible to call method for data on virtual registers

SIMD vectorized types

I think this change is going to be significant in larger codebases, as the current test project is only about 4 files. So the improvement is only 15% to 20%
If these phases were not parallel, in a larger codebase, the total time taken would have been so high, so the speedup from parallelisation would be higher

Speedup update - The compilation & linking phase is now `15% to 20%` faster
The compilation of LLVM IR files (.ll) to Object files is one phase
The bundling of object files to libraries and linking to executable is another phase
- So first, all llvm files are compiled to object files in parallel for all modules. Then the compiler waits for this phase to complete
- Then, libraries and executables are linked from the object files, in parallel, and compiler waits for all to finish

That applies to arbitrary bitwidth integers as well. Like `u100`

Currently writing the standard library. Working on the string.qat file right now. Finished implementations for `unsigned_to_string:[T]`, `signed_to_string:[T]` and `float_to_string:[T]` which works for any of the numerical types supported by the language