| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a block value is evaluated, the address tracker is immediately
incremented for each word in the evaluated block. This was causing an
issue when a block value was passed as an argument to a macro
invocation, because argument values would all be evaluated before the
macro body was evaluated. This meant that the value of every label in
the macro body would be pushed forward by the size of the block
argument, even if the block argument is inserted later in the macro.
Furthermore, the address tracker would be incremented exactly once
for each word in the block, even if the block is never inserted into
the macro or is inserted multiple times.
To fix this, we now defer evaluation of a block argument until exactly
when that block argument is inserted into a macro. Because a block
argument could be an invocation with a set of arguments passed to it,
we also store a copy of the current environment alongside the block
value so that it can be evaluated correctly at any time in the future.
|
| |
|
|
| |
This simplifies the next commit.
|
| |
|
|
|
|
| |
This allows an integer invocation with arguments to be wrapped in `[]`
square brackets so that it can be passed to another invocation as an
argument.
|
| | |
|
| |
|
|
|
|
| |
This variant was never needed or constructed, I would have added it to
match the invocation variants of the block and integer tokens (which do
have a use).
|
| |
|
|
|
|
| |
This is preferable to having the assembler crash with a stack overflow
error, because the user can now see which invocation caused the
overflow.
|
| |
|
|
|
| |
This completes the Torque version 3 rewrite, other than some extensive
testing that is yet to be done.
|
| |
|
|
|
|
|
|
| |
Massive improvement. Label references can be used anywhere in the
program, with the program being assembled repeatedly until all labels
have stabilised. The bytecode stage will just be a tiny stage tacked
onto the end, rather than the old bytecode stage that would resolve
labels and expressions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a relaxation of the rule where a label reference could not
be used in any context that could change the length of an assembled
program.
We implement this in the bytecode stage by naively calculating an
initial address for each label as before. If a pinned address is
calculated from a label reference, some of the calculated addresses
could be incorrect. We then attempt to run the bytecode stage, which
will calculate a more accurate address for each label based on how
pinned addresses are calculated. If the address of any label was
changed by running this stage, we re-run the stage up to three more
times until all labels stabilise. If the labels fail to stabilise, we
return an error.
|
| |
|
|
|
|
|
|
|
|
|
| |
This feature promotes strings to a first-class type in the language.
If a string is passed to an invocation via the new string-type argument,
the string will be passed as a whole value. String arguments can still
be passed to an invocation via an integer-type argument, in which case
they'll be broken apart into individual characters with the macro being
invoked once per character.
String-type macro arguments are declared like "name".
|
| |
|
|
|
|
|
| |
A macro can now invoke itself if the invocation is inside a conditional
block that will eventually return false. The assembler stack can still
overflow if the macro recurses too deeply, or if a macro calls itself
without a conditional block.
|
| |
|
|
|
| |
This will currently cause the assembler to hang in all situations where
it is used.
|
|
|
The language is now more general, the code is better structured, error
reporting is more detailed, and many new language features have
been implemented:
- conditional blocks
- first-class strings
- more expression operators
- binary literals
- negative values
- invocations in constant expressions
|
