| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
MALLOC_STACK is a stack based version of MALLOC, SUB does subtraction.
|
|
Happened because we weren't printing all relevant words due to
naturally flooring the result of division. Here I ceil the division
to ensure we get the maximal number of words necessary.
|
|
|
|
|
|
|
|
Very easy, they just pop a word then defer to their normal versions.
This is probably the best case where a macro works directly so I
didn't even need to write a function form for them first. One thing
is that then names for the macros are quite bad right now, probably
need renaming.
|
|
Essentially they use the stack for their one and only operand. This
allows user level control, in particular it allows for loops to work
correctly while using these operands.
|
|
|
|
|
|
This will allow for more library level code to be written. For
example, say you wanted to write a generic byte level reversal
algorithm for dynamically sized allocations. Getting the size of the
allocation would be fundamental to this operation.
|
|
|
|
Pretty simple implementation, nothing massive.
In VERBOSE mode, heap is tracked for any allocations/deletions,
printing it if so.
|
|
Pretty simple, required some new types of errors. Obviously there's
space for a macro for the differing instruction implementations, but
these things need to be tested a bit more before I can do that.
|
|
One may allocate any number of (bytes|hwords|words), set or get some
index from allocated memory, and delete heap memory.
The idea is that all the relevant datums will be on the stack, so no
register usage. This means no instructions should use register space
at all (other than POP, which I'm debating about currently). Register
space is purely for users.
|
|
As PUSH_REGISTER and MOV have the same signature of taking a word as
input, DUP may as well be part of it.
This leads to a larger discussion about how signatures of functions
matter: I may need to do a cleanup at some point.
|
|
|
|
Instead of having each page be an area of memory, where multiple
pointers to differing data may lie, we instead have each page being
one allocation. This ensures that a deletion algorithm, as provided,
would actually work without destroying older pointers which may have
been allocated. Great!
|
|
Now need to create some instructions which manage the heap
|
|
A page is a flexibly allocated structure of bytes, with a count of the
number of bytes already allocated (used) and number of bytes available
overall (available), with a pointer to the next page, if any.
heap_t is a linked list of pages. One may allocate a requested size
off the heap which causes one of two things:
1) Either a page already exists with enough space for the requested
size, in which case that page's pointer is used as the base for the
requested pointer
2) No pages satisfy the requested size, so a new page is allocated
which is the new end of the heap.
|
|
|
|
|
|
|
|
|
|
word register 0 refers to the first 8 bytes of the dynamic array.
Hence the used counter should be at least 8 bytes. This deals with
those issues. Also print more useful information in
vm_print_registers (how many byte|hword|word registers are currently
in use, how many are available).
|
|
Dependencies are just ASM_OUT binary and the corresponding assembly
program for the bytecode output file. Actually works very well, with
changes triggering a recompilation. Also an `exec` recipe is
introduced to do the task of compiling an assembly program and
executing the corresponding bytecode all at once.
|
|
|
|
Very cool, easy, and reads well
|
|
|
|
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.
|
|
|
|
Thankfully multiplication, like addition, is the same under 2s
complement as it is for unsigned numbers. So I just need to implement
those versions to be fine.
|
|
By default I initialise the registers with 8 words, though this may
not be necessary for your purposes.
|
|
This is because comparators may apply to signed types, so I need to
use the right parsing function.
|
|
This is using the comparators and a jump-if
|
|
As registers may be theoretically infinite in number, we should use
the largest size possible when referring to them in bytecode (a word).
|
|
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.
|
|
This means the stack should be heap allocated, which makes sense as
beyond 1KB one should really be using the heap rather than the stack.
|
|
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.
|
|
This is only new data allocated, so it's a very careful procedure.
|
|
|
|
|
|
|
|
|
|
Much simpler, uses a switch case which is a much faster method of
doing the parsing. Though roughly equivalent in terms of LOC, I feel
that this is more extensible
|
|
More useful tokens, in particular for each opcode possible. This
makes parsing a simpler task to reason as now we're just checking
against an enum rather than doing a string check in linear time.
It makes more sense to do this at the tokeniser as the local data from
the buffer will be in the cache most likely as the buffer is
contiguously allocated. While it will always be slow to do linear
time checks on strings, when doing it at the parser we're having to
check strings that may be allocated in a variety of different places.
This means caching becomes a harder task, but with this approach we're
less likely to have cache misses as long as the buffer stays there.
|
|
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.
|
|
This pushes a datum of the same type as the operands, which is why it
cannot use the comparator macro as that always pushes bytes.
|
