| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
Now that we don't have to edit code to run a single test, delete that
commented out fragment everywhere.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Mostly for tests. For every new type we want to compare in a test, we're
now going to start using some primitive that can parse its value from string. In this manner we can get syntax for literals in machine code.
Open question: parsing aggregates of aggregates. Like an array of structs.
This is the first time we allocate from the heap in standard library tests.
So we now need to start initializing the heap in all our apps.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now SubX defines headers with the following syntax:
```
=== ...
```
The `...` can be either a numeric address or a name. Numeric addresses
are useful for tests where we want to check addresses of individual instructions.
Names are useful in real programs where we want to add to a segment in
many places.
This approach has long seemed a mess. It's hard to explain, and there's
a certain amount of historical evolution that led to it that should be
irrelevant to comprehend the current state of the codebase. I started out
assuming the first segment was always code, before adding the special names
'code' and 'data'. We pretend to support more than two segments but we
don't really.
To simplify the code and explanation we'll move to a new syntax:
```
=== <name> <address>
```
Code will always belong in the special name 'code', but it no longer has
to be first.
We need to migrate both our SubX-in-SubX phases and the C++ version. The
plan is to start from the top down and update bootstrapping phases that've
already been built (see commit 5102 for the list of phases). This commit
updates pack.subx. Current state:
✓ hex.subx (no changes required)
survey.subx
✓ pack.subx (fixed here)
assort.subx
dquotes.subx
|
| |
|
|
|
| |
Operations on buffered-file now always include the word 'buffered'. More
verbose, but hopefully this highlights holes in the library.
|
| |
|
|
|
| |
Pull in a _different_ function than `next-word` (commit 5092) into a shared
file between phases. Let's see how this goes.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Realization: 'next-word' can't be reused in converting string literals,
because it has to understand string literals.
Let's just keep each phase self-contained.
|
| |
|
|
|
|
|
| |
Start using the new newline escape in string literals everywhere.
I could use it more aggressively, but it makes tests harder to read. So
only one line of text per string for now.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fail early when writing to a fake file runs out of space. Makes debugging
tests easier.
Reads from files, on the other hand, are only buffering to a temporary
stream, so it makes sense to silently stop when they run out of space.
In the process I uncovered a testing bug in pack.subx: I was missing a
trailing space in the expected result, but the test still passed because
the space was getting truncated. Being principled about aborting on overflow
by default will help avoid such issues.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
write-stream-buffered isn't a clean abstraction. Ignoring the 'read' index
of a stream is a hack. It's just saving us the trouble of a rewind-stream.
So make it a helper of pack.subx rather than part of the standard library.
|
| | |
|
| |
|
|
| |
Done with pack.subx?!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Testing conversion of multiple lines in a data segment.
Bugs fixed:
1. Stack issues in next-token helpers.
2. Needed to teach next-token to avoid newlines.
3. rewind-stream(line) before passing it to convert-code or convert-instruction.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several bugs found after performing multiple loops through convert-data.
This has been a general pattern: given how unsafe the x86 'language' is,
the regular amount of testing with a single input doesn't really give sufficient
confidence. Ever-present is the possibility that I forgot to pop something
from the stack, either a spilled register or a local. Calling functions
multiple times seems to help detect such bugs. So far I've been doing this
extra level of testing implicitly when I build the next higher abstraction.
But with `convert-data` the buck stopped, and much painful debugging ensued.
One thing that would help is if `write` on streams didn't remain silent
on overflow. But we actually need that sometimes, when streams are used
as buffers.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|