Parser v2?

[Kroc]

It has occurred to me that another method of parsing would be to use a straight jump table from ASCII code to routine. Since the order of tokens would no longer be enforced by code order (i.e. a value must follow a unary operator), there would instead be a "mode" variable that would describe the context for each routine arrived at. For example, if an operator is encountered but the mode says we're not in an expression, then we throw an error.

There are a number of cons:

• The parsing flow is much harder to follow
• One token is not connected to another by code flow meaning that register pressure may increase
• A mode value needs to be persisted and this may be difficult to pin to a register (as above)
• the ASCII jump table will take ~192-256 bytes

However there are some pros:

• Less code is required to express parsing; may actually save bytes
• Less code also means less code to port for other architectures, such as porting v80 to 6502 (v65?)
• Less coupling of routines, easier to make improvements without knock-on effects

[Kroc]

Had an idea: Writing to the code-segment could be done via a routine that has the current code-segment address in the LD instruction, avoiding having it pinned to IY if we have another need for it? This adds a call for writing to the code-segment, but most calls will be eliminated with the move to a char jump-table. This would depend upon IX/IY being better used for something else that requires the offset capability (heap records?)

[Kroc]

I would like to have a fast path for numbers that avoids the full expression parser, but we can't know if a number is alone or part of an expression ahead of time as we must look for the operator that follows.

There are two approaches to this we could follow:

1. Read the value and if an operator follows, start the expression with the initial value provided beforehand
2. Require all expressions using operators to use parenthesis, i.e. ($1+ $2) so that the presence of an operator may be known beforehand

[Kroc]

The nightmare of eZ80's (#12) prefix splurge means looking at a potential replacement instruction parser. When I began writing the instruction parser one idea I toyed with was a prefix-based list where the first byte/nybble specifies how many chars are shared with the previous entry, and the instructions are all listed alphabetically, dictionary like. I couldn't be sure it would save enough space, so I went with the tree but I need to make a working version of the list to see if it would help with eZ80 encoding.

[Kroc]

After a couple of months, the results are in:

- #size_of_opcodes      $0F35 (ISA1)
                        $0FAA (ISA2)
- #size_of_parseISA     $0050
- #size_of_parseISA2    $0084

Cycles:
- v1:   139,215,546
- v2:   109,007,184

The new instruction parser is marginally larger (there's still room for optimisation) but, save for yet-unseen bugs, is also faster! I didn't expect this, but I'll take the win after all that work; this will make adding new ISAs much easier on everybody

[Kroc]

ISA parser v2 has been merged greatly simplifying the way ISAs are written.