This function only responsibility is writing opcodes and operands to a
bal_instruction_t and adding it to the instruction stream.
Signed-off-by: Ronald Caesar <github43132@proton.me>
Also added the size of each array to bal_engine_t to make finding the
end of the array in memory simple and easy.
Signed-off-by: Ronald Caesar <github43132@proton.me>
I want users of Ballistic to design their own memory allocators. Their memory
allocation requirements will most likely be different from ours, so providing
users the API to write their own allocators gives them a lot of freedom
to do whatever they feel is best. This idea was inspired in part by the Zig
programming language.
Signed-off-by: Ronald Caesar <github43132@proton.me>
Having 18-bit opcodes means a block has at most 131,072 instructions
which is simply too big. All of these instructions cannot fit into the
L1 cache, which results in cache thrashing.
Signed-off-by: Ronald Caesar <github43132@proton.me>
We have enough bits in the opcode bitfield in instruction_t
to encode register classes (ADD_INT, ADD_FLOAT, ADD_VECTOR). However,
encoding the bit width (ADD_INT8, ADD_INT32) will massively increase the
amount of opcodes needed. So we replace `type` in ssa_version_t with
`bit_width`.
Signed-off-by: Ronald Caesar <github43132@proton.me>
Rule 4.2 states: "If a basic block is deemed cold, it should move to a
separate buffer." This violates Rule 3.1 Implicit Indexing. If v100 is
located at instructions[100] and we move it to a cold buffer, it id no
longer at index 100. If we keep the index 100 but store the data
elsewhere, you break the linear memory array performance benefits.
Hot-cols splitting will be done during code generation.
Signed-off-by: Ronald Caesar <github43132@proton.me>
- Replace value-returning IFs with Void IFs and explicit OPCODE_MERGE.
- Move SSA definitions to block exits to eliminate backpatching.
- Formalize Control Scope Stack for tracking yields and arity.
- Update loop peeling logic to respect new merge semantics.
Signed-off-by: Ronald Caesar <github43132@proton.me>
This attribute originally got removed because you could determine the
type of the variable based on the instruction opcode.
For example:
x1 = OPCODE_ADD_INT32 y1, 10.
x1 type is an int32.
We cannot apply this to control instructions because that would bloat
the amount of opcodes needed. An opcode has 10 bits, so we can define
1024 opcodes. Adding different variations for an `IF` instruction alone
would fill uo way to much space:
x1 = IF_INT8 (condition)
x1 = IF_INT16 (condition)
x1 = IF_INT32 (condition)
x1 = IF_UINT8 (condition)
x1 = IF_FLOAT (condition)
x1 = IF_VECTOR (condition)
etc...
So to solve creating unecessary opcodes, ssa_version_t will hold the
variable type instead:
x1 = IF (condition) DEF_TYPE: INT32
ssa_version_t.type = DEF_TYPE
Signed-off-by: Ronald Caesar <github43132@proton.me>
instruction[i] defines ssa_versions[i]. So it doesnt make sense to have
the attribite `defining_instruction_index`.
Signed-off-by: Ronald Caesar <github43132@proton.me>
Demonstrates how the SSSA model will work on a while loop. I plan to add
more examples to iron out the flaws of the model.
Signed-off-by: Ronald Caesar <github43132@proton.me>
This model is designed for fast code execution speed which is something
we do not want. We care about compilation speed, so we will focus on
implementing the Structures SSA model.
Signed-off-by: Ronald Caesar <github43132@proton.me>
