about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 5001 - drop the :(scenario) DSLKartik Agaram2019-03-1285-11234/+13399
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've been saying for a while[1][2][3] that adding extra abstractions makes things harder for newcomers, and adding new notations doubly so. And then I notice this DSL in my own backyard. Makes me feel like a hypocrite. [1] https://news.ycombinator.com/item?id=13565743#13570092 [2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning [3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2 The implementation of the DSL was also highly hacky: a) It was happening in the tangle/ tool, but was utterly unrelated to tangling layers. b) There were several persnickety constraints on the different kinds of lines and the specific order they were expected in. I kept finding bugs where the translator would silently do the wrong thing. Or the error messages sucked, and readers may be stuck looking at the generated code to figure out what happened. Fixing error messages would require a lot more code, which is one of my arguments against DSLs in the first place: they may be easy to implement, but they're hard to design to go with the grain of the underlying platform. They require lots of iteration. Is that effort worth prioritizing in this project? On the other hand, the DSL did make at least some readers' life easier, the ones who weren't immediately put off by having to learn a strange syntax. There were fewer quotes to parse, fewer backslash escapes. Anyway, since there are also people who dislike having to put up with strange syntaxes, we'll call that consideration a wash and tear this DSL out. --- This commit was sheer drudgery. Hopefully it won't need to be redone with a new DSL because I grow sick of backslashes.
* 5000Kartik Agaram2019-03-121-1/+1
| | | | Fix spurious errors in `test_layers` on non-Linux platforms.
* 4999Kartik Agaram2019-03-107-1/+3
| | | | | | | | Fix CI. pack.subx was passing in emulation but not natively. Commit 4954 on Feb 10 was a real dud. First I find I forgot to reclaim space for locals (commit 4996). Now I find I haven't been tracking registers properly either.
* 4998Kartik Agaram2019-03-091-0/+5
| | | | | | | Start running binaries natively in test_layers as well. CI is still broken; need to investigate where my SubX emulation has a discrepancy with native x86.
* 4997Kartik Agaram2019-03-094-32/+40
|
* 4996 - back on pack.subxKartik Agaram2019-03-0811-309/+412
| | | | | | | | | Yet another redrawing of responsibilities between convert and its helpers. In the process I discovered a bug in `write-stream-buffered` which ended up taking me through a detour to extract `browse_trace` into its own tool. It turns out just having long buffers is enough to need browse_trace. Simple operations like clearing a stream swamp a flat view of the trace.
* 4995Kartik Agaram2019-03-061-1/+2
| | | | | Thanks Peter van Hardenberg for causing me to run into this crash (the first time I tried to demo sandboxes in a long time).
* 4994Kartik Agaram2019-03-034-22/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bring back support for incrementally printing the trace to the screen (stderr). I previously thought I didn't need this as long as I'm always incrementally saving to the 'last_run' trace file. But I quickly ran into a use for it: when I want to see a complete trace including switching into the sandbox's trace and back out again. So there are now two separate commandline flags: --trace to save the trace to file --dump to print the trace to screen The former won't handle sandbox traces. But the latter will. I'm deemphasizing --dump in the help message since it should be rarely used. One other situation where I've used stderr in the past is for just raw convenience. But trying to always use the trace was a foolish consistency. Conclusion: a) For simple debugging, feel free to just use cout/cerr. Delete them before committing. b) If the prints get too complex, switch to the trace and browse_trace tool. c) If using nested sandboxes, emit to stderr, redirect to file, and browse_trace. I've gone back and forth on these questions in the past; now I'm trying to be a little more rigorous about capturing reasoning.
* 4993Kartik Agaram2019-03-032-4/+6
| | | | | Fix CI after commit 4987. And track stack depths more correctly inside sandboxes.
* 4992Kartik Agaram2019-02-272-0/+6
|
* 4991Kartik Agaram2019-02-251-3/+4
|
* 4990Kartik Agaram2019-02-251-1/+1
|
* 4989Kartik Agaram2019-02-2531-2038/+2136
|
* 4988Kartik Agaram2019-02-256-0/+0
|
* 4987 - support `browse_trace` tool in SubXKartik Agaram2019-02-2573-998/+1326
| | | | | | | | | | | | | | | | | | I've extracted it into a separate binary, independent of my Mu prototype. I also cleaned up my tracing layer to be a little nicer. Major improvements: - Realized that incremental tracing really ought to be the default. And to minimize printing traces to screen. - Finally figured out how to combine layers and call stack frames in a single dimension of depth. The answer: optimize for the experience of `browse_trace`. Instructions occupy a range of depths based on their call stack frame, and minor details of an instruction lie one level deeper in each case. Other than that, I spent some time adjusting levels everywhere to make `browse_trace` useful.
* 4986 - spending some time improving SubX tracesKartik Agaram2019-02-232-10/+15
| | | | | | Now that our test runs are getting longer, debugging is again becoming a bottleneck. Time to start using trace depths along with `mu browse-trace` from the top-level.
* 4985Kartik Agaram2019-02-231-0/+5
|
* 4984Kartik Agaram2019-02-221-1/+1
|
* 4983Kartik Agaram2019-02-227-66/+67
| | | | | | | Standardize name for 'end of file' sentinel. `eof` seems like an ordinary variable, and `EOF` looks too much like a register (particularly in code like `if (EAX == EOF)`), so we'll go with `Eof`. Consistent capitalization for globals, and constants are globals too.
* 4982Kartik Agaram2019-02-1860-12259/+12251
|
* 4981 - no, go back to 3 phasesKartik Agaram2019-02-1845-234/+130
| | | | | | | | | | | | | 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.
* 4980Kartik Agaram2019-02-181-8/+8
|
* 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
|