about summary refs log tree commit diff stats
path: root/subx/034compute_segment_address.cc
Commit message (Collapse)AuthorAgeFilesLines
* 5001 - drop the :(scenario) DSLKartik Agaram2019-03-121-49/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 4987 - support `browse_trace` tool in SubXKartik Agaram2019-02-251-4/+4
| | | | | | | | | | | | | | | | | | 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.
* 4981 - no, go back to 3 phasesKartik Agaram2019-02-181-16/+16
| | | | | | | | | | | | | 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.
* 4959Kartik Agaram2019-02-131-10/+29
| | | | | 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.
* 4771Kartik Agaram2018-11-241-0/+2
| | | | | | | I stopped handling disp16 at some point, and using instructions with such an operand messes up segment alignment when generating ELF binaries. I don't test my ELF generation. This is a sign that maybe I should start.
* 4761Kartik Agaram2018-11-231-1/+1
| | | | | Bugfix: I forgot about ELF segment offsets when implementing VMAs. Eventually segments grew large enough that I started seeing overlaps.
* 4754 - allow data segment to refer to variablesKartik Agaram2018-11-191-8/+10
|
* 4668Kartik Agaram2018-10-051-3/+3
|
* 4661Kartik Agaram2018-10-041-17/+17
| | | | | Make segment management a little more consistent between initial segments and add-on segments (using `mmap`).
* 4637 - subx: support multiple input filesKartik Agaram2018-10-011-3/+62
|
* 4631Kartik Agaram2018-10-011-0/+10
|
* 4614 - redo simulated RAMKartik Agaram2018-09-291-2/+0
| | | | | | | | | | | Now simulated 'Memory' isn't just a single flat array. Instead it knows about segments and VMAs. The code segment will always be first, and the data/heap segment will always be second. The brk() syscall knows about the data segment. One nice side-effect is that I no longer need to mess with Memory initialization regardless of where I place my segments.
* 4565Kartik Agaram2018-09-211-0/+15
|
* 4550Kartik Agaram2018-09-201-1/+2
|
* 4544Kartik Agaram2018-09-121-1/+1
| | | | | | | | Attempt #3 at fixing CI. In the process the feature gets a lot less half-baked. Ridiculously misleading that we had `has_metadata()` was special-cased to one specific transform. I suck.
* 4535 - support for global variable namesKartik Agaram2018-09-011-2/+26
|
* 4534Kartik Agaram2018-09-011-0/+31
I'd been planning to add segment address computation after all labels were computed, including labels in the data segment (which isn't built yet). But now I realize that won't work, because labels in the data segment will require segment start addresses. We need to deal in absolute addresses rather than relative offsets as with the jump instructions that use code labels. Layer 34 is now broken by this change in a way that isn't obvious right now: it is oblivious to imm32 and disp32 operand tags that are now going to be present in the programs it sees. It's a lucky accident that everything still works, because we're only using segment names right now for the very first (code) segment in a program.