Assembling the Assembler

Grammar fix

When starting implementing the compiler part of this. I noticed that the grammar does not actually really work, especially if you introduce new lines. If I parse a file with 3 instructions, we catch the \n sometime and the asm-comment token is too greedy.

Let's change the ws rule to only capture horizontal blank (space and tab) and introduce an eol token, this makes the grammar more clear on what we are working on also.

Capturing thing

With grammar in Raku, you associate an Action class to your grammar to transform the AST or just do what you want when you encounter a token.

It's really a simple mechanism, you define a class with methods that have the same name as your token and that's all. You don't need to have a method for every token and for our purpose we mainly only need to catch the <instruction> tokens. The catch for our code, since we use a proto token for <instruction> and multiple generated token like token instruction:sym<TRB-DIRECT-PAGE> defining an instruction method does not work. The method must match the name of the generated token, but we don't need to generate a method for every token since Raku offers a pseudo method called FALLBACK that catch-all method calls on our class that are not defined.

The method look like this :

The instructions are stored in a CompilableInstruction class to make them more interesting to use.

I removed my generated array of instructions and replaced it with a %map-instructions that map my instruction information according to their 'name' and their addressing mode. This will be very useful to report what addressing mode an instruction support in case of error.

Today I learn - Be mindful of $/

You can see that I named the Match argument of FALLBACK to $match. In most grammar examples it will be named $/ like the implicit variable affect when you use a regex. But it's a small trap. You can see that I use a regex to match and capture part of the method name so $/ get reaffected and you get a runtime error that tell you that you affected a read-only variable (method/sub arguments are read only by default)

Getting the value

We also need to capture the operand of the instruction, we could get it at grammar level and add the value to the ast when parsing a byte, word or long, but you need to propagate the change the ast for each parent token up to the instruction. There is a more simple solution, you can note that I assign the operand with an attribute called last-value it's because I simply catch each byte, word, long token in the action class and affect them to this attribute.

I actually don't use the ValueType for now, but maybe that will be useful later.

Showing the result

Next step is to write a Str/gist method on the CompilableInstruction class to have a nice output so we can display the @.instructions from the action class. This array is built from the @!see-instructions when we encounter a <one-instruction> or <instruction-line> token. This is probably not needed now, but my previous grammar was causing some instruction to be seen twice on a bad match.

Let assemble one of my small test files.

I also wrote a sub to display the value according to the addressing mode so the Str method can 'rebuild' the text.

The program output look like this, so far so good

To generate the bytecode I just add an assemble method on my instruction class that returns a buf8 containing the bytes from the instruction information. It's actually pretty straightforward since we just need to take the op-code and append the encoded operand in LittleEndian.

The next step will be to test if the produced output is valid. So we will need to write tests and compare with other assemblers.