Instead of going left and right, finding operators chars and replacing them
with nulls, we parse expressions in a more orderly manner, one chunk at a
time. I think it qualifies as "recursive descent", but I'm not sure.
This allows us to preserve the string we parse and should also make the
implementation of parens much easier.
This should make tests a bit more convenient to write and debug.
Moreover, begin de de-IX-ization of parseExpr. I have, in a local WIP, a
parseExpr implemented using a recursive descent algo, it passes all tests, but
it unfortunately assembles a faulty zasm. I have to find the expressions that
it doesn't parse properly.
But before I do that, I prefer to commit these significant improvements I've
been making to tests harness in parallel of this development.
Also, add a "real world" example in AVRA tests, a blink program on
a ATtiny45. Some instructions are commented out because they aren't
implemented yet, but not many.
The output of the program has been verified against AVRA's own
output.
Use IX directly for argspec rows instead of going through DE. It saves a bit
of processing. The code was this way because I initially didn't use IX at all,
so as code evolved, that DE translation stayed as an artifact.
We now treat the block device as fixed-size rather than trying to grow it in response
to kernel activity.
Previously, if you tried to create 2 files in a row, only the first 1 would actually appear,
because the device only ever got larger when a byte was written immediately past the end of
the device.
Now we just let the kernel write bytes to the disk anywhere, so new files can be created even
when the previous file is not completely full.
Also, fix buffer overrun in reading filesystem image, and use a more idiomatic fgetc loop.
By uploading a BASIC loop and then run it, we can reduce the serial
communication to pure content which greatly reduces the overhead and make
the process much much faster.
I know, this is silly, but I'm moving tools to something a bit closer to the
system. I consider perl to be more system-like than python for a simple reason:
perl is part of the OpenBSD base system and python is not.
Also, I'm learning perl and using this as an opportunity.
This gives the maximum size of the stack at any given moment during the
execution of the program. It's useful to figure out if the stack gets
dangerously close to the heap.
