| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
It's a little hacky in some corner cases. In particular, if debug information
isn't available the trace will contain duplicated lines. This is because
I don't want the core trace lines all my tests rely on (introduced in the
'vm' layer) to have to know about debug info (introduced in the 'labels'
and 'debug' layers).
Thanks Charles Saternos for the feedback and suggestion!
|
| |
|
|
| |
Rename '--map' to '--debug'.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
handle newlines
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Temporary title for HN submission.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been allowing operands in any order just because it simplifies implementation.
I don't actually rely on this flexibility; all the .subx programs in this
repo consistently use a single ordering.
Why is a hard-coded canonical order hard to implement? The order that seems
most logical to me is complicated by the "reg" bits in the ModR/M byte:
- In instructions that interpret it as an `/r32` operand, it needs to be
deemphasized because it refers to a different argument of the instruction
than the `/mod`, `/rm32`, `/base`, `/index` and `/scale` operands that
capture the bulk of instruction decoding complexity and so should be
emphasized. `/r32` can also be unused, which strengthens the case for
deemphasizing it.
- In instructions that interpret the "reg" bits as a `/subop` operand,
it should be colocated with the opcode because it performs the same function:
specifying the *operation* the instruction performs.
In both cases, the bits in the `reg` bitfield are conceptually unrelated
to the other bitfields in the same byte. But they sometimes want to be
close to the opcode bytes on the left, and at other times need to be deemphasized
rightward. Fixing both these possibilities seems complicated and stateful,
particularly since all operands are optional in general. On the other hand,
just pulling operands you need to create each byte, regardless of where
in the instruction they occur, that's nicely stateless.
|
| | |
|
| |
|
|
|
| |
It's always seemed ugly to explain the rules for segment names. Let's just
always require a fixed name for the code and data segments.
|
| |
|
|
| |
Improve syntax highlighting in the Readme.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
In the process of building next-token I finally added some support for a
debugging situation I've found myself in a couple of times: wondering "what
changed this memory location"?
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Experimenting with putting code examples higher up in the Readme. Thanks
Pelle Hjek for the feedback: http://arclanguage.org/item?id=20875.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|