| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
| |
A cascading if-else structure is more readable than a set of nested
match expressions.
|
| |
|
| |
|
|
|
|
|
| |
Work-in-progress commit while functionality is moved over to the
assembler crate. This commit doesn't compile.
|
|
|
|
|
| |
Work-in-progress commit while functionality is moved over to the
assembler crate. This commit doesn't compile.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The source unit merge order as of commit 1f25783 was merging head files
in the correct order to ensure that macro definitions were merged before
any references, but it didn't ensure that the main file of the root
source unit was merged before any other main files. This was, in some
cases, causing library code to be inserted before program metadata and
initialisation code in the assembled program.
This was fixed by using different merge orders for head files, and for
main and tail files.
|
| |
|
|
|
|
|
|
|
|
| |
The padding for the line numbers in the left margin was being calculated
from the length of the zero indexed line number, but the value being
printed was the one-indexed line number, so the margin would be offset
by a character when an error occurred on a one-indexed line number that
was a power of ten.
|
|
|
|
|
|
|
|
| |
When a library contains only macro definitions, the definitions will
be kept in the .head.brc file and the main .brc file will be empty. To
prevent from cluttering the merged source file with path comments for
empty files, the contents of the file are first checked, and if the
file contains only whitespace it will not be merged.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A SourceSpan contains up to two SourceLocations: the location of the
span in the parsed source file (called in_merged), and the location of
the span in an original source file as per a path comment in the parsed
source file (called in_source). In places where only one location can
be reported, the in_source location is preferred but is not guaranteed
to exist, so the in_merged location is used as a fallback.
Because this pattern is used in multiple places, it was added as a
method to SourceSpan and all occurrences of the pattern were replaced
with a method call.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reported location of the original definition of a redefined symbol
was incorrect. The index stored alongside a redefined symbol was the
ID of the source unit which owns the original definition, but in the
error printing code it was being treated as the index of the original
definition of that symbol in the definitions list of the resolver. This
was causing the reported location of the original definition to be that
of an unrelated symbol.
To fix this issue, the index stored alongside a redefined symbol is now
the index of the original definition of that symbol in the definitions
list of the resolver.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is to prevent the main source of another zero-dependency source
unit from being merged before the main source of the root source unit,
which would cause a program to immediately enter into library code when
run.
The root source unit is always the main source code, and other source
units are library code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous source merging strategy was to concatenate source units
in the reverse order that they were added to the resolver, which
generally only worked when each source unit had at most one
macro-resolving parent.
An issue arose when some macros in a source unit were resolved by a
source unit which had been added earlier in the order, as the required
macro definitions would then be merged after they were referenced,
preventing the program from assembling.
The new source merging strategy finds an optimal merge order by first
recording for a given source unit the ID of each unit which resolves a
macro referenced by the given unit, and then only merging those source
units whose macro-defining dependencies have already been merged. In the
case that a cycle is detected, where two or more source units depend on
one another, a message is printed and the assembly is aborted.
|
| |
|
|
|
|
|
| |
Previously only the path to the source file was being written, not the
location of the symbol within the file.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is an almost complete rewrite of the entire assembler from the
ground up, with a different parsing strategy and a whole new symbol
resolution mechanism for automatically including library files.
The assembly syntax has also been slightly modified, with padding
tokens now being prefixed with '#' instead of '$', and a block-style
anonymous-label syntax which uses the '{' and '}' characters.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
- The LKD and SKD operations have been removed
- SHF/SHC have been moved to after LDD/STD
- SWP/ROT/DUP/OVR have been rearranged to be DUP/OVR/SWP/ROT
- NOT/AND have been rearranged to be AND/NOT
- PSK has been added, placed after PSH
- SPL has been added, placed after POP
|
|
|
|
|
|
|
| |
The assembler previously reported only the length of the generated
bytecode in bytes. It now also reports the program size as a percentage
of the maximum program size of 64KB, to give the user an idea of how
close they are to hitting the program size limit.
|
| |
|
|
|
|
|
| |
Don't print the internal error representation to the console when an
error occurs while trying to write the assembled bytecode to stdout.
|
|
|
|
|
|
| |
The JMP and JSR op-codes no longer include a * character, and the
double-mode JCN op-codes have been changed to JSN to reflect a change
in the instruction set of the Bedrock processor.
|
|
|
|
|
|
| |
When the assembler successfully assembles a program, it will now report
the names of all label definitions for which there are no label references.
This is to aid the user in finding dead code within their programs.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the assembler encounters an error, the erroneous line and the line
number are output in order to help the user to find where in the input
file the error occurred. This is useful for single-file inputs, but the
line number is generally not helpful if the input file was generated by
concatenating multiple files.
In order to help the user to determine where in the program source the
error occurred, the assembler now reports the name of the label which
directly precedes the erroneous line.
|
|
|
|
|
|
| |
Double-quoted strings are automatically terminated by null bytes, with
single-quoted strings maintaining the prior non-terminated string
behaviour.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Previously, attempting to write large amounts of bytecode to stdout
would often result in only the first n bytes being written.
|
|
|
|
|
| |
This will break unix pipelines in order to prevent any emulator down the
pipeline from attempting to run a malassembled program.
|
| |
|
| |
|
| |
|
|
|