| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Clean up some old TODOs related to our pre-mmap limitations.
Also caught another case of using the wrong comparison. When comparing
addresses, one must always use unsigned rather than signed jump instructions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Still some failing tests:
- emit-string-literal-data doesn't ignore metadata when computing the
length of literal strings
- emit-string-literal-data doesn't handle escape sequences
One issue doesn't have a failing test:
- emit-metadata doesn't handle string literals containing '/'
All these open issues involve a common design question: how to parse a
'word' that includes a string literal that may include spaces.
For everything else I know words can't contain spaces and datums can't
contain slashes. But for string literals things are tougher.
|
| |\
| |
| |
| |
| | |
dquotes.subx is now segfaulting after this merge. Seems to be trying to
use addresses from the old stack.
|
| | |
| |
| |
| |
| | |
Skimping on tests; the code changes seem pretty trivial. Will this fix
CI?!
|
| | |
| |
| |
| |
| |
| |
| | |
Pretty blunt for now; just abort the entire program on any failure to write.
I'm encountering it because I'm somehow treating a stream address as a
file descriptor. Maybe mmap is returning addresses below 0x08000000?
|
| | |
| |
| |
| |
| | |
Bugfix: I'd neglected to update the input stream's state when natively
writing a stream to file.
|
| | | |
|
| |\|
| |
| |
| | |
Segfault in this branch is now fixed.
|
| | |
| |
| |
| |
| | |
All tests passing now. Things are very explicit; before a program can `allocate`
memory, it has to first obtain a segment from the OS using `new-segment`.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
These are variants of write-byte-buffered and print-byte-buffered respectively
that operate on in-memory `stream`s rather than `buffered-file`s.
They don't operate on files, so we'll avoid using the prefix 'write-'.
|
| |/
|
|
|
| |
Operations on buffered-file now always include the word 'buffered'. More
verbose, but hopefully this highlights holes in the library.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Fix CI. pack.subx was passing in emulation but not natively.
Commit 4954 on Feb 10 was a real dud. First I find I forgot to reclaim
space for locals (commit 4996). Now I find I haven't been tracking registers
properly either.
|
| |
|
|
|
|
|
|
|
| |
Yet another redrawing of responsibilities between convert and its helpers.
In the process I discovered a bug in `write-stream-buffered` which ended
up taking me through a detour to extract `browse_trace` into its own tool.
It turns out just having long buffers is enough to need browse_trace. Simple
operations like clearing a stream swamp a flat view of the trace.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Considering how much trouble a merge phase would be (commit 4978), it seems
simpler to just add the extra syntax for controlling the entry point of
the generated ELF binary.
But I wouldn't have noticed this if I hadn't taken the time to write out
the commit messages of 4976 and 4978.
Even if we happened to already have linked list primitives built, this
may still be a good idea considering that I'm saving quite a lot of code
in duplicated entrypoints.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Starting to build up Phase 2 (apps/pack) out of recently designed primitives.
|
| | |
|
| | |
|
| |
|
|
| |
Cleaner way to compare streams in tests.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Clean up primitives for converting from/to hex chars.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We want slice-equal? for length-prefixed strings, not null-terminated "kernel"
strings.
|
| | |
|
| |
|
|
|
| |
In the process of building slice primitives I found an out-of-bounds access
in write-byte.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Fix CI.
a) Update canonical binaries.
b) Fix an out-of-bounds access in `clear-stream`. This also required supporting
a new instruction in `subx run` to load an imm8 into rm8.
|
| |
|
|
| |
We only can't use rm32=5 when mod=0. Totally fine when it's mod=1.
|
| | |
|