Age | Commit message (Collapse) | Author |
|
Also error now points to the correct place in the file.
|
|
|
|
We have distinct functions for the use blocks and the macro blocks,
which each generate wholesale new token streams via `token_copy` so we
don't run into weird errors around ownership of the internal strings
of each token.
Furthermore, process_presults now uses the stream index in each
presult to report errors when stuff goes wrong.
|
|
So when a presult_t is constructed it holds an index to where it was
constructed in terms of the token stream. This will be useful when
implementing an error checker in the preprocessing or result parsing
stages.
|
|
So %USE <STRING> is the expected call pattern, so there's an error if
there isn't a string after %USE.
The other two errors are file I/O errors i.e. nonexistent files or
errors in parsing the other file. We don't report specifics about the
other file, that should be up to the user to check themselves.
|
|
Forgot to increment buffer->used and memcpy call was just incorrect.
|
|
This essentially just copies the internal string of the token into a
new buffer.
|
|
|
|
|
|
This is different to "%CONST" in that it can take token parameters and
use them. This allows the construction of user code at compile time,
which can be very useful for a variety of use cases.
|
|
Essentially importing another file *literally* into the file. This
would happen before parse results are gathered, similar to how
"%CONST" is implemented currently.
|
|
|
|
Doesn't do much, invalid for most operations.
|
|
Stuff like numeric limits can be codified in constants which act self
documenting.
|
|
|
|
|
|
Preprocessor handles macros and macro blocks by working at the token
level, not doing any high level parsing or instruction making.
Essentially every macro is recorded in a registry, recording the name
and the tokens assigned to it. Then for every caller it just inserts
the tokens inline, creating a new stream and freeing the old one. It
leaves actual high level parsing to `parse_next` and
`process_presults`.
|
|
|
|
|
|
When an error occurred, because prog->ptr was incremented beforehand
the trace would show the next instruction as the culprit rather than
the actual instruction. This commit fixes that by incrementing the
program if and only if the command was run successfully.
|
|
|
|
Lots to refactor and test
|
|
|
|
|
|
|
|
|
|
|
|
This would be useful when writing an interpreted language where the
"assembly" and the "execution" occur within the same executable.
|
|
|
|
|
|
|
|
This is mostly so labels get to have digits. This won't affect number
tokens as that happens before symbols.
|
|
|
|
Looks way more high level but parses down to a very simple bytecode.
However, because of lack of inline code processing, it relies on the
call stack quite heavily. With inline labels this would be a much
more compact bytecode.
|
|
|
|
Implementing start points has made features necessary for a standard
library setup easier to see.
|
|
|
|
Was used in a previous fix but not necessary anymore
|
|
In vm_execute_all set the program pointer to the start address in the
header of the program payload.
|
|
|
|
Set the program structure correctly with a header using the parsed
global instruction.
|
|
|
|
Very barebones, essentially a simple refactor.
I need to introduce a feature to append to a program as well, but as
it's a flexible structure it will likely have to be functional.
|
|
Essentially a "program header", followed by a count, followed by
instructions.
Provides a stronger format for bytecode files and allows for better
bounds checking on instructions.
|
|
Creates a jump address to the label delegated by "global" so program
starts at that point.
|
|
Some considerations as to how to do this (dynamic or static linking)
and changes needed in VM/assembler for this to work.
|
|
|
|
|
|
|
|
|