Previously, all calculations regarding stack depth and label depth
were broken. *All* of them. Off-by-ones, the logic was wrong, etc.
Variables are still screwed up, but I'm *almost* there, where
"there" is being able to generate functioning programs, hopefully?
Still pretty horribly broken. I was generating dispacements
backwards, failing to emit stuff like the beginning of
loops, the logic for `if` jumps was backwards, etc.
I was also completely forgetting to increment file_here
for appends. I don't remember what all I did; check the diff.
Next stages are to wire it into the parser so I can test it,
to implement operator precedence so exprs actually exist,
and then implement operators and builtins until I can
start writing basic programs.
Now I know that the parser is LL(1) and the lexer also only
needs one-character lookahead, which allows me to dramatically
simplify the interface for IO input, and improve the interface
to the lexer. Even if I did want unbounded peek, I'd want
the interface to be `peek(off)`, not that awful buffer.
I intend to use the new lexer interface to make the parser
states more stateful, and potentially read multiple tokens
in a row. Then, states would only be needed for recursive
structures, without the awkward intermediate states like
ST_LABEL which exists only to let me burn a token.
I also removed the nonsense related to base 64 parsing,
because it was unclear how to handle it, and the advantages
of having it weren't clear. I kept up to base 36, but honestly
I might want to consider getting rid of everything but decimal,
hex, and binary anyway. I'm not sure if I'd want to keep using
the current syntax for the radix either.
Also no top-level declarations or operator precedence.
The syntax is LL(1). LL syntax seems necessary because
our codegen requires emitting certain code (e.g. entering control)
prior to any codegen inside that context, whereas something like
LR would presumably parse the inner expression before recognizing
the control structure. There may be some way to work around this;
I don't know, I'm not a parsing expert.
Certain parts of the syntax are wonky, e.g. juxtaposition as
function application means a missing semicolon can give confusing
results. I suspect indentation-sensitive syntax would work
more nicely, and intend to implement it some time in the future.
I don't need some fancy atomic output file updating or
posix_fadvise. I removed all platform-specific code
except for a single `chmod`.
That's not to say there's no advantage to atomically
reading or writing files, but for this project, the first
rule needs to be KISS. It's premature optimization and
overengineering.
Now we always use the stack instead of keeping a TOS register.
This is very inefficient, but I'll worry about register
allocation later.
The new block model is inspired by x86's `enter` and `leave`
instructions. I intend to support nested procedures at some point
in the future.
James T. Martin