| Age | Commit message (Collapse) | Author |
|---|
|
Makes more sense, don't need to fiddle around with strings as much in
the parser due to this!
|
|
Not necessary when you can just push the relevant word onto the stack
then just do OP_JUMP_STACK.
|
|
Essentially a presult_t contains one of these:
1) A label construction, which stores the label symbol into
`label` (PRES_LABEL)
2) An instruction that calls upon a label, storing the instruction
in `instruction` and the label name in `label` (PRES_LABEL_ADDRESS)
3) An instruction that uses a relative address offset, storing the
instruction in `instruction` and the offset wanted into
`relative_address` (PRES_RELATIVE_ADDRESS)
4) An instruction that requires no further processing, storing the
instruction into `instruction` (PRES_COMPLETE_INSTRUCTION)
In the processing stage, we resolve all calls by iterating one by one
and maintaining an absolute instruction address. Pretty nice, lots
more machinery involved in parsing now.
|
|
|
|
|
|
|
|
|
|
|
|
This is because comparators may apply to signed types, so I need to
use the right parsing function.
|
|
Much simpler, uses a switch case which is a much faster method of
doing the parsing. Though roughly equivalent in terms of LOC, I feel
that this is more extensible
|
|
|
|
Just takes the character literally as a number.
|
|
|
|
Introduced some functions to parse differing types of opcodes. Use
the same style of a.b.c... for namespacing or type specification for
certain opcodes. Bit hacky and not tested, but does work.
Parse errors can be reported with an exact location using the token
column, line.
|
|
|
|
|
|
No implementations yet
|
