Lucky surprise: OP_PLUS follows the same principle rules as the
bitwise operators in that they return the same type as the input.
Therefore I can simply use the same macro to implement it and MULT as
those. Very nice.
This is because: say we have {a, b} where a is on top of the stack. A
comparator C applies in the order C(b, a) i.e. b `C` a. The previous
version did a `C` b which was wrong.
Stack based machines generally need "variable space". This may be
quite via a symbol-to-word association a list, a hashmap, or some
other system. Here I decide to go for the simplest: extending the
register system to a dynamic/infinite number of them. This means, in
practice, that we may use a theoretically infinite number of indexed
words, hwords and bytes to act as variable space. This means that the
onus is on those who are targeting this virtual machine to create
their own association system to create syntactic variables: all the
machinery is technically installed within the VM, without the veneer
that causes extra cruft.
A negative number under 2s complement can never be equal to its
positive as the top bit *must* be on. If two numbers are equivalent
bit-by-bit then they are equal for both signed and unsigned numbers.
Anything other than char (which can just use print.byte to print the
hex) and byte (which prints hexes anyway), all other types may be
forced to print a hex rather than a number if PRINT_HEX is 1.
I've made a single macro which defines a function through some common
metric, removing code duplication. Not particularly readable per se,
but using a macro expansion in your IDE allows one to inspect the code.
These new members are just signed versions of the previous members.
This makes type punning and usage for signed versions easier than
before (no need for memcpy).
