| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
I've started testing more regularly on 64-bit Linux, and I realize that
the binaries actually now compare identical even on 64-bit. Why did I ever
add that condition to CI? Seems to be working now on Travis. Let's start
comparing now and see if the problem happens again.
|
|
|
|
|
|
|
| |
I'm still trying to figure out what the defaults should be. At the moment
you have to explicitly pass in every file you want loaded into the output
binary. Maybe that control is a good thing. The examples need no libraries
so far.
|
|
|
|
|
|
|
|
| |
Start requiring a '-o' flag to designate the output binary when translating.
Things currently get funky if you pass in multiple inputs, but that's ok.
This is the first step to supporting multiple input files for a single
output binary.
|
| |
|
| |
|
| |
|
|
|
|
| |
The teensy/ examples have outlived their usefulness, I think.
|