about summary refs log tree commit diff stats
path: root/subx/Readme.md
Commit message (Collapse)AuthorAgeFilesLines
* 5481Kartik Agaram2019-07-261-2/+7
|
* 5480Kartik Agaram2019-07-261-2/+2
|
* 5469Kartik Agaram2019-07-251-1/+1
|
* 5466 - demo self-hosting in ReadmeKartik Agaram2019-07-241-0/+23
|
* 5462 - What's next for Mu? Look here.Kartik Agaram2019-07-241-28/+13
|
* 5459Kartik Agaram2019-07-231-4/+6
|
* 5430 - all examples passingKartik Agaram2019-07-201-1/+2
| | | | | We now have a new pass called 'tests' which code-generates a new function called 'run-tests', just like the C++ layer `tests.cc`.
* 5424Kartik Agaram2019-07-191-12/+12
|
* 5423Kartik Agaram2019-07-191-1/+1
|
* 5415Kartik Agaram2019-07-171-6/+6
| | | | | | | | Bugfix thirteen: displacement calculations were wrong because current offset was not being updated properly as words were being read and emitted. Now 10/12 example programs are translated correctly.
* 5414Kartik Agaram2019-07-171-4/+4
|
* 5410 - 4 examples passingKartik Agaram2019-07-171-1/+22
| | | | | Clean up other examples as well to satisfy the requirements in commit 5404.
* 5403Kartik Agaram2019-07-141-3/+3
|
* update roadmap in subx/ReadmeKartik Agaram2019-07-141-7/+1
|
* update library docsKartik Agaram2019-07-091-5/+13
|
* 5226Kartik Agaram2019-05-271-3/+4
|
* 5225Kartik Agaram2019-05-271-9/+9
|
* 5224Kartik Agaram2019-05-271-1/+2
|
* 5223Kartik Agaram2019-05-251-3/+3
|
* 5215Kartik Agaram2019-05-201-0/+2
|
* switch to new syntax for segment headers in C++Kartik Agaram2019-05-181-3/+4
|
* complete the skeleton of dquotes.subxKartik Agaram2019-05-151-1/+7
| | | | | | | | | | | | | | | | 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.
* new primitives: append-byte, append-byte-hexKartik Agaram2019-05-021-0/+4
| | | | | | | 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-'.
* standardize function namesKartik Agaram2019-05-021-4/+6
| | | | | Operations on buffered-file now always include the word 'buffered'. More verbose, but hopefully this highlights holes in the library.
* 5133 - show instruction source in traceKartik Agaram2019-04-281-0/+1
| | | | | | | | | | 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!
* 5131Kartik Agaram2019-04-271-7/+8
| | | | Rename '--map' to '--debug'.
* 5130 - only show build status of 'master' branchKartik Agaram2019-04-271-1/+1
|
* 5129Kartik Agaram2019-04-271-29/+32
|
* 5128Kartik Agaram2019-04-261-9/+48
|
* 5111Kartik Agaram2019-04-181-3/+3
|
* 5091Kartik Agaram2019-04-131-3/+6
|
* Add support for escape sequences in string literals fixed traces so they can ↵nc2019-04-131-5/+0
| | | | handle newlines
* 5086Kartik Agaram2019-04-121-0/+8
|
* 5083Kartik Agaram2019-04-111-1/+2
|
* 5082Kartik Agaram2019-04-111-2/+3
|
* 5078Kartik Agaram2019-04-111-4/+4
|
* 5071Kartik Agaram2019-04-101-12/+15
|
* 5070Kartik Agaram2019-04-101-1/+1
|
* 5069Kartik Agaram2019-04-101-7/+7
|
* 5068Kartik Agaram2019-04-101-1/+1
| | | | Temporary title for HN submission.
* 5067Kartik Agaram2019-04-101-11/+11
|
* 5066Kartik Agaram2019-04-101-253/+223
|
* 5053Kartik Agaram2019-04-031-1/+0
| | | | | | 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.
* 5032Kartik Agaram2019-03-291-1/+2
|
* 5031Kartik Agaram2019-03-291-9/+10
|
* 5030 - docs for library functions created so farKartik Agaram2019-03-291-12/+137
|
* 5006Kartik Agaram2019-03-161-0/+1
|
* 4981 - no, go back to 3 phasesKartik Agaram2019-02-181-15/+14
| | | | | | | | | | | | | 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.
* 4977Kartik Agaram2019-02-161-4/+8
|
* 4976 - recommend that operand order be fixedKartik Agaram2019-02-161-14/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-22 11:40:42 +0000