| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Fix CI.
For some reason allocating 4KB natively on Linux triggers a segfault. Temporarily
reducing segment size to 256 bytes; that's large enough for the test. But
it's not a long-term solution. Maybe I need to grow the heap with sbrk()?
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current plan for SubX translator:
$ cat files.subx ... |assort |pack |survey |hex > a.out
Higher-level notations will be inserted at the start of the pipeline. The
first (and needed for bootstrapping) is for string literals.
$ cat files.subx ... |string-literals |assort |pack |survey |hex > a.out
Alternatively, we should check how often we use string literals and just
convert them by hand.
They're used all over in tests, and converting them would make tests hard
(even harder) to read.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|