Lightweight meta-assembler https://code.benbridle.com/torque-asm/atom?h=v3.0.1 2025-12-30T01:29:54Z 2025-12-30T01:29:54Z Ben Bridle ben@derelict.engineering 2025-12-30T01:29:54Z urn:sha1:aecc8e439f7360be65d37aa88c0c522434e00881 2025-12-30T01:29:19Z Ben Bridle ben@derelict.engineering 2025-12-30T00:26:34Z urn:sha1:a7cfcd4ba9e86dce6d8366dc4122704a49d3909d 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. 2025-12-30T01:00:45Z Ben Bridle ben@derelict.engineering 2025-12-29T20:09:40Z urn:sha1:c5e626d27910e82df125d6d0c09037811488eeea This simplifies the next commit. 2025-12-30T01:00:45Z Ben Bridle ben@derelict.engineering 2025-12-30T00:20:26Z urn:sha1:0de8aef53a2e9e86340bae3d051a1d5d8372ec99 When a macro definition body contains more than one token, every token must be a block token. When a non-block token is included in one of these macro definitions, an error points to the offending token and says that a block token was expected in this macro definition. The change that this commit makes is to also point to the top of the macro definition to make it clearer that this macro definition is part of the problem, not just the errant integer or list by itself. Without this, the error message could be read to say that the integer or list itself is a macro definition, which could be confusing. 2025-12-04T04:03:55Z Ben Bridle ben@derelict.engineering 2025-12-04T03:59:53Z urn:sha1:29e847768ae5d6fe7e631c668d23536729dbe8d8 This commit includes the arity of a parent macro in the namespace of a macro argument, so that the assembler library can recognise that two macro implementations with different arities are not the same. This fixes an error where two implementations of a macro with the same name but different arity could not share argument names, because the arity of the parent macro wasn't being taken into account when checking for redefinitions. 2025-12-04T03:51:03Z Ben Bridle ben@derelict.engineering 2025-12-04T03:51:03Z urn:sha1:938b40dd15f1d44f8881261a64e092fc0fd9165b 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. 2025-11-26T06:24:14Z Ben Bridle bridle.benjamin@gmail.com 2025-11-26T06:24:14Z urn:sha1:091938b459e9f6e7a9ed4e5427da535d0cb693f3 2025-11-26T06:22:13Z Ben Bridle bridle.benjamin@gmail.com 2025-11-26T06:13:45Z urn:sha1:80ea0d650e3d8f56e43df21f1293b4ddccb89203 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). 2025-10-26T20:59:49Z Ben Bridle bridle.benjamin@gmail.com 2025-10-26T03:53:46Z urn:sha1:20a029a3215d1e9816812c3484f65164b8faa613 The single-quote character is used in register names on some processor architectures. The double-quote character is also allowed to be used in identifiers for consistency, it could be confusing otherwise. 2025-10-19T22:54:48Z Ben Bridle ben@derelict.engineering 2025-10-19T22:54:48Z urn:sha1:120b6f7043937cb1b72f2d52f6cb97fb5d0e3fc6 Every other operation has a three-letter name, so this change makes the operation names more consistent.