about summary refs log tree commit diff stats
path: root/subx/Readme.md
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* 4972Kartik Agaram2019-02-151-1/+3
|
* 4959Kartik Agaram2019-02-131-2/+1
| | | | | 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.
* 4944Kartik Agaram2019-01-301-4/+4
| | | | Improve syntax highlighting in the Readme.
* 4943Kartik Agaram2019-01-301-2/+2
|
* 4925Kartik Agaram2019-01-141-1/+1
|
* 4915Kartik Agaram2019-01-081-0/+6
| | | | | | 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"?
* 4873Kartik Agaram2018-12-201-5/+11
|
* 4866Kartik Agaram2018-12-101-6/+6
|
* 4858 - debugging tipsKartik Agaram2018-12-081-0/+103
|
* 4825Kartik Agaram2018-12-031-15/+15
|
* 4795Kartik Agaram2018-11-281-3/+3
|
* 4794Kartik Agaram2018-11-281-1/+1
|
* 4793Kartik Agaram2018-11-281-9/+46
| | | | | Experimenting with putting code examples higher up in the Readme. Thanks Pelle Hjek for the feedback: http://arclanguage.org/item?id=20875.
* 4791Kartik Agaram2018-11-271-13/+14
|
* 4789Kartik Agaram2018-11-271-4/+4
|
* 4786Kartik Agaram2018-11-261-1/+1
|
* 4785Kartik Agaram2018-11-261-1/+1
|
* 4784Kartik Agaram2018-11-261-1/+1
|
* 4783Kartik Agaram2018-11-261-0/+46
|
* 4781Kartik Agaram2018-11-261-9/+11
|
* 4779Kartik Agaram2018-11-261-54/+95
|
* 4778 - entirely rewritten ReadmeKartik Agaram2018-11-251-133/+264
|
* 4730Kartik Agaram2018-10-281-1/+1
|
* 4727 - commit to better 64-bit supportKartik Agaram2018-10-271-3/+2
| | | | | | | 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.
* 4638 - extract some common libraries from appsKartik Agaram2018-10-011-1/+1
| | | | | | | 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.
* 4624Kartik Agaram2018-09-301-2/+2
| | | | | | | | 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.
* 4623Kartik Agaram2018-09-301-73/+89
|
* 4529 - move examples to a sub-directoryKartik Agaram2018-09-011-11/+10
|
* 4506Kartik Agaram2018-08-121-2/+2
|
* 4462Kartik Agaram2018-07-301-4/+4
| | | | The teensy/ examples have outlived their usefulness, I think.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-07-07 20:11:57 +0000