It replaces the IR-FETCHVAR's result with the variable being
fetched. This only works when the only use is in an operation that
does not require a separate fetch be performed, such as those
implemented as CPU instructions.
The compiler middle stage takes high level nodes and produces code in
an intermediate representation more closely resembling assembly code.
Optimizations and the tools for making those are also included. It's
significantly easier to optimize IR than syntax trees or assembly.
Several things need cleaning up, in particular there are things in
jigs.lisp that really should be documented tools, not
jigs (specifically the compilation setup and finalization).
It ingests tokens via a "token stream", and feeds out a node
tree. It's a mostly handwritten recursive descent parser with the
occasional Lisp macros for convenience.
The new nodes are more directly representational of the syntax, and
code generation will be moved to an intermediate stage with a more
linear (yet still node-based) representation.
I just couldn't stand "dotimes x 200", and "for x do 200 times" just
feels so much nicer. I also added a space after an opening parenthesis
to ensure that my tokenizer gets to eat this particular type of
unnecessary but permitted whitespace.
That revert before? I was kidding, I concede nothing! I win! (i.e. we
talked for a while and both decided that an argument vector was better
after all)
