about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 4979Kartik Agaram2019-02-182-1/+112
|
* 4978 - maybe we need another phaseKartik Agaram2019-02-171-0/+36
| | | | | | | | | | | | | | Phase 1: coalesce different instances/fragments for each segment, correctly prepending later fragments. Phase 2: pack bitfields into bytes. Phase 3: compute addresses for labels, compute the ELF header. Phase 4: convert hex bytes to binary. But ugh, phase 1 involves linked lists and I'll have to go down a rabbit hole building up more standard library functions.
* 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.
* 4975 - new plan for Phase 2Kartik Agaram2019-02-161-4/+36
| | | | | | So far I've been assuming that I'd just statelessly convert each line in a .subx file. But over the past week or so of constant interruptions I gradually realized that code and data need different parsers.
* 4974Kartik Agaram2019-02-151-1/+1
| | | | Fix CI.
* 4973Kartik Agaram2019-02-1520-89/+120
| | | | | Support immediate operands in the data segment in all the ways we support them in the code segment.
* 4972Kartik Agaram2019-02-151-1/+3
|
* 4971 - clean up a few scriptsKartik Agaram2019-02-1510-29/+57
| | | | | | | | | | | | | Some of them are no longer useful; drop them. For the rest, have useful usage messages. And also be a little more principled in where we introduce CFLAGS, and where we expect it to come in from the commandline. I'm choosing not to call gen/run/dgen/drun from test_layers because it makes test_layers harder for newcomers to read. The scripts aren't the first thing people should see, they're just useful once you're up and running hacking on SubX.
* 4970Kartik Agaram2019-02-151-4/+4
|
* 4969Kartik Agaram2019-02-151-2/+2
|
* 4968Kartik Agaram2019-02-148-635/+1186
|
* 4967Kartik Agaram2019-02-1425-4338/+4387
|
* 4966Kartik Agaram2019-02-144-24/+23
| | | | Standardize how we show register allocation decisions.
* 4965Kartik Agaram2019-02-147-25/+31
|
* 4964Kartik Agaram2019-02-142-3/+3
|
* 4963Kartik Agaram2019-02-144-9/+9
|
* 4962Kartik Agaram2019-02-141-38/+40
| | | | | Build the C++ version optimized by default when building/running all apps. We have enough apps now that the cost of optimized builds is worthwhile.
* 4961Kartik Agaram2019-02-1431-209/+253
|
* 4960Kartik Agaram2019-02-132-8/+6
| | | | | I think I don't need to special-case packing for different segments. That should massively cut down on the number of tests.
* 4959Kartik Agaram2019-02-133-105/+142
| | | | | 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.
* 4958 - all my apps fit in 4KB so farKartik Agaram2019-02-111-0/+16
| | | | (excluding tests)
* 4957Kartik Agaram2019-02-119-1477/+2007
|
* 4956Kartik Agaram2019-02-112-1/+69
|
* 4955Kartik Agaram2019-02-108-20/+380
| | | | Starting to build up Phase 2 (apps/pack) out of recently designed primitives.
* 4954Kartik Agaram2019-02-109-39/+141
|
* 4953Kartik Agaram2019-02-0521-2139/+3012
|
* 4952Kartik Agaram2019-02-059-13/+474
|
* 4951Kartik Agaram2019-02-0316-78/+273
| | | | Cleaner way to compare streams in tests.
* 4950Kartik Agaram2019-02-0315-0/+0
|
* 4949Kartik Agaram2019-02-0224-42/+62
|
* 4948Kartik Agaram2019-02-023-577/+1588
| | | | | This seems like the final helper we need for Phase 2. Now to build the business logic itself.
* 4947Kartik Agaram2019-02-012-0/+2
| | | | | | | | Bugfix: has-metadata? was corrupting registers Seems uneconomic to write tests for stuff like this. Assembly is just not the right layer to try to come up with a general solution or process. Keep running your code and wait to find signs of breakage.
* 4946Kartik Agaram2019-02-012-2/+66
|
* 4945Kartik Agaram2019-02-017-0/+70
|
* 4944Kartik Agaram2019-01-301-4/+4
| | | | Improve syntax highlighting in the Readme.
* 4943Kartik Agaram2019-01-302-3/+2
|
* 4942Kartik Agaram2019-01-214-324/+337
|
* 4941Kartik Agaram2019-01-211-4/+17
|
* 4940Kartik Agaram2019-01-211-4/+4
|
* 4939Kartik Agaram2019-01-213-3/+253
|
* 4938Kartik Agaram2019-01-208-721/+729
|
* 4937Kartik Agaram2019-01-208-452/+1282
|
* 4936Kartik Agaram2019-01-182-20/+20
|
* 4935Kartik Agaram2019-01-161-2/+2
|
* 4934Kartik Agaram2019-01-164-6/+6
|
* 4933Kartik Agaram2019-01-167-50/+50
|
* 4932Kartik Agaram2019-01-1614-836/+1443
|
* 4931Kartik Agaram2019-01-161-1/+0
|
* 4930Kartik Agaram2019-01-157-2/+231
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-16 13:56:16 +0000