This week, my work was mainly focused on finishing the assembler simplification I talked about last week.

In the first instance I started working on a fairly basic but not very efficient simplification, which can be seen in PR #132. From the text of the PR itself it reads:

This is a WIP of the assembler simplification.
The main idea is to drop the use of the pending vector that accumulates bytecodes until the definition of a label is reached.

There is still a lot to optimise, but the general idea is as follows:

• Scan the code to identify labels and macros (surely this can be removed).
• Process the code in its entirety, expanding macros where possible and saving label positions as they appear.
• A final pass to concretise all the labels, assigning them their corresponding value.

As I said before, this is still a work in progress, as I don't think it's necessary to do three passes through the code.

However, this first approach gave me a deeper understanding of how the assembler works, and I noticed that the simplification in question could be tackled without the need for several of the operations used in the previous PR. Therefore, I decided to tackle the problem from scratch again and that is how PR #133 was born. We can see the basic ideas of this implementation from the text of the PR itself:

This PR simplifies the operation of the assembler, mainly by removing the need to maintain a pending state and to return the assembler to its original state in certain situations (which caused issue #124).

The main changes include:

• The creation of two structs, PendingMacro and PendingLabel, which store information about the macros and labels used before they were defined, as well as their relative position in the code.
• Some push operations have been changed to take an option as parameter, and if this is not None, to act more like an insert than a push (useful for example to insert the calls to the pending macros).

Also, issue #124 has been fixed and the corresponding test added.

All tests should pass successfully. However, I would like to test the new assembler a bit more by writing some code (e.g. following @lightclient 's recommendation and writing an ERC-20 implementation using ETK) before merging it.

In case you don't find it necessary, it can be merged right now.

As mentioned in the same text, this PR also solves issue #124, which was in the list of "possible tasks after EOF" that I talked about with lightclient.

While all the tests pass correctly, I'm interested in testing the code a bit more by implementing some short example code, like an ERC20, which can also serve to add to the examples section of the documentation, which is empty at the moment.

---

So, the tasks for next week are:

• Implement a version of the ERC-20 standard in ETK to add to the list of examples and, by the way, look for possible bugs in the assembler.

• Follow up on the EOF implementation and the possible modifications we were going to make to solve the opcode renaming/deprecation issue I talked about a few weeks ago.