The 'source' directory compiles, but the repl and tests are almost
untouched so far. There's no guarantee that the code in 'source' is
correct, so I'm branching this for a short time, until I'm confident the
whole project passes the CI again.
I'm adjusting the concepts of routines and bytecode to make them more
consistent, and tweaking the VM so it loads from an instance of
'Toy_Module'.
* 'Toy_ModuleBuilder' (formally 'Toy_Routine')
This is where the AST is compiled, producing a chunk of memory that can
be read by the VM. This will eventually operate on individual
user-defined functions as well.
* 'Toy_ModuleBundle' (formally 'Toy_Bytecode')
This collects one or more otherwise unrelated modules into one chunk of
memory, stored in sequence. It is also preprended with the version data for
Toy's reference implementation:
For each byte in the bytecode:
0th: TOY_VERSION_MAJOR
1st: TOY_VERSION_MINOR
2nd: TOY_VERSION_PATCH
3rd: (the number of modules in the bundle)
4th and onwards: TOY_VERSION_BUILD
TOY_VERSION_BUILD has always been a null terminated C-string, but from
here on, it begins at the word-alignment, and continues until the first
word-alignment after the null terminator.
As for the 3rd byte listed, since having more than 256 modules in one
bundle seems unlikely, I'm storing the count here, as it was otherwise
unused. This is a bit janky, but it works for now.
* 'Toy_Module'
This new structure represents a single complete unit of operation, such
as a single source file, or a user-defined function. It is divided into
three main sections, with various sub-sections.
HEADER (all members are unsigned ints):
total module size in bytes
jumps count
param count
data count
subs count
code addr
jumps addr (if jumps count > 0)
param addr (if param count > 0)
data addr (if data count > 0)
subs addr (if subs count > 0)
BODY:
<raw opcodes, etc.>
DATA:
jumps table
uint array, pointing to addresses in 'data' or 'subs'
param table
uint array, pointing to addresses in 'data'
data
heterogeneous data, including strings
subs
an array of modules, using recursive logic
The reference implementation as a whole uses a lot of recursion, so this
makes sense.
The goal of this rework is so 'Toy_Module' can be added as a member of
'Toy_Value', as a simple and logical way to handle functions. I'll
probably use the union pattern, similarly to Toy_String, so functions
can be written in C and Toy, and used without needing to worry which is
which.
I was coding earlier this week, but my brain was so foggy I ended up not
knowing what I was doing. After a few days break, I've cleaned up the
mess, which took hours.
Changes:
* Variables can be assigned
* Added new value types as placeholders
* Added 'compare' and 'assign' to the AST
* Added duplicate opcode
* Added functions to copy and free values
* Max name length is 255 chars
* Compound assigns are squeezed into one word
To be completed:
* Tests for this commit's changes
* Compound assignments
* Variable access
I was reworking bits of the containers to address issue #131, then
realized that the table's tests depended on a specific initial size. I'm
too buggered to finish it tonight, so I'll fix it tomorrow.
This wasn't an easy fix, as it was primarily the test pipelines that
were failing. I resorted to using forced pushes to run the CI, to try
and track down the problems.
The primary cause seems to be the differences in how each supported
platform handles file paths, specifically, slash vs. backslash.
I've also added gdb scripts to set up automated breakpoints, and to run
operations on them to check for issues - the 'gdb_init' files are mostly
empty for the time being.
commit a34b0ff5d407bbe7d70ff9504aa035ec6fbecb7c
Author: Kayne Ruse <kayneruse@gmail.com>
Date: Fri Oct 18 11:45:40 2024 +1100
Restored the workflows
commit eb3d94f30d4dc4150139517f44cc874f2901124f
Author: Kayne Ruse <kayneruse@gmail.com>
Date: Fri Oct 18 11:35:39 2024 +1100
I think the library path on macos is fixed
commit 964572b5e93c7cb464686f19ddbe3e9d315f391b
Author: Kayne Ruse <kayneruse@gmail.com>
Date: Fri Oct 18 11:22:56 2024 +1100
I think the file paths are fixed
commit 1721f3da7252b4063f4347926e800ef4f7c9bf4c
Author: Kayne Ruse <kayneruse@gmail.com>
Date: Thu Oct 17 15:57:28 2024 +1100
Added standalone tests
commit 90c783f4059d88f4a7bbaf18215a9b414f3ab66f
Author: Kayne Ruse <kayneruse@gmail.com>
Date: Thu Oct 17 15:01:18 2024 +1100
Trying to fix the integration test pipeline
commit fccced1396568a55c1385e2f1b04fedf7c2585a5
Author: Kayne Ruse <kayneruse@gmail.com>
Date: Wed Oct 16 00:31:39 2024 +1100
Workflow integration tests are not passing
commit 6b1e0d1e0f89291e89768bf6102f4f7ed4581496
Author: Kayne Ruse <kayneruse@gmail.com>
Date: Tue Oct 15 20:07:20 2024 +1100
Fixed file paths in workflow
commit c0f1ec78fe79a5abb34c3e05308236cb18c23b97
Author: Kayne Ruse <kayneruse@gmail.com>
Date: Tue Oct 15 19:46:14 2024 +1100
Moved example scripts into proper integration tests
Also adjusted makefiles to allow easy invoking of the tests.
Adjusted and updated CI to invoke tests correctly.
Fixed#141
The tests are failing in a strange way, with the error message 'corrupted top size'. I don't know what it means, and it seems to be caused by a call to printf() within 'test_bytecode.c'. I need a break, as this is making me dizzy.
