this mostly switches from using a resizeable hash table to store macros
and whatnot to using a binary search tree (i was having some heisenbugs
with the hash table that i didn't really feel like debugging it).
a BST has a simpler implementation and uses a bit less memory, however
it is potentially slower (O(log n) vs O(1)) & less cache performant
however, currently i care more about ease of implementation so i can
muck about with my impl without running into bugs. when i care more
about performance i will probably revert this change (or rewrite a
working hash table), but not without benchmarks
as:$ keep flag
keep flag, whether to decrement the stack pointers for
the arguments used in the instruction
e.g. (a--n) --> (a--a n)
this is useful in situations where we want to keep the
arguments on the stack to do something else with, e.g.
a lot of the times we'll do `du fb` or something. now
we can save bytes and just do `$fb`. yippee!
{d/kmm32-as,s/vim}:{document,highlight} ^ literal
this allows us to create relative addresses easily
eg. `pr ^l ju :l ;` & `pw @l ju :l ;` are equivelant
this also enables us to easily make pascal-style (?)
length-prefixed strings, given the string size is <127:
`:str ^l "meow" :l ; ;`
`pr x` (where x is a byte) puts ip+(int8)x onto the stack
eg. `pr #04 ju xx yy zz` skips bytes xx&yy and jumps to zz
0 1 2 3 4
^
+- relative to
this allows us to cut down by a full 3 bytes when referring
to labels that are closer than 128 bytes away, and allows
us to relocate less labels
(if we ever have relocatable binaries or something)
Kitty-Cricket Piapiac