about summary refs log tree commit diff stats
path: root/subx/014indirect_addressing.cc
Commit message (Collapse)AuthorAgeFilesLines
* bug: null address messing up instruction decodeKartik Agaram2019-07-091-2/+7
| | | | Leads to a bad error message.
* switch to new syntax for segment headers in C++Kartik Agaram2019-05-181-71/+71
|
* 5160Kartik Agaram2019-05-151-4/+4
|
* start using the new carry flagKartik Agaram2019-05-131-12/+11
| | | | | Skimping on tests; the code changes seem pretty trivial. Will this fix CI?!
* flag tests for opcode 3bKartik Agaram2019-05-131-3/+61
|
* .Kartik Agaram2019-05-131-12/+9
| | | | | | Standardize layout of some code fragments, and fix several bugs in computing the overflow flag in the process. a64 = b32 + c32 doesn't benefit from `a` being 64-bit without casting `b`.
* flag tests for opcode 2bKartik Agaram2019-05-131-7/+69
|
* flag tests for opcode 03Kartik Agaram2019-05-131-7/+69
|
* carry flag thoroughly tested in layer 13Kartik Agaram2019-05-131-1/+1
| | | | | This is time-consuming mostly for me to come up with example scenarios testing all the different combinations of flags.
* .Kartik Agaram2019-05-131-11/+11
| | | | Correct some confusing log messages.
* CF needs special handling for some arithmetic opsKartik Agaram2019-05-121-10/+56
| | | | Inline some macro definitions.
* snapshot of carry flag implementationKartik Agaram2019-05-121-14/+19
| | | | | | | | | | | | | | | | | | Tests failing. This approach seems wrong. I'm not sure even the tests are correct. Also, some open questions: 1. Should setting the overflow flag always set the carry flag? 2. Should the carry flag only be set on add/subtract/compare, or by all arithmetic ops? 3. Had to turn off the -ftrapv flag in `build`. Is there a way to detect overflow without actually causing overflow? Once we start setting CF correctly we have to implement jump above/below instructions (8- and 32-bit displacement variants). https://github.com/akkartik/mu/issues/30
* 5152 - check for stack underflow/overflow in VMKartik Agaram2019-05-111-6/+7
|
* 5001 - drop the :(scenario) DSLKartik Agaram2019-03-121-342/+505
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-23/+23
| | | | | | | | | | | | | | | | | | 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.
* 4718Kartik Agaram2018-10-241-5/+5
|
* 4717Kartik Agaram2018-10-241-38/+38
|
* 4715 - support one more negation instructionKartik Agaram2018-10-231-1/+1
|
* 4695Kartik Agaram2018-10-141-18/+18
|
* 4694Kartik Agaram2018-10-131-9/+9
| | | | Check for duplicate docstrings.
* 4693Kartik Agaram2018-10-131-9/+9
| | | | | | | | Add the standard mnemonic for each opcode. We aren't ever going to have complete docs of the subset of the x86 ISA we support, so we need to help readers cross-correlate with the complete docs.
* 4689Kartik Agaram2018-10-121-64/+0
|
* 4688Kartik Agaram2018-10-121-28/+28
|
* 4687Kartik Agaram2018-10-121-11/+11
|
* 4686Kartik Agaram2018-10-121-5/+5
|
* 4685Kartik Agaram2018-10-121-1/+1
|
* 4634Kartik Agaram2018-10-011-91/+91
|
* 4503Kartik Agaram2018-09-221-0/+23
| | | | Include LEA (load effective address) in the SubX subset of x86 ISA.
* 4584 - discrepancy between SubX and native x86Kartik Agaram2018-09-211-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | One of the more painful things I had to debug with machine code. Tricks I used can be seen in ex10.subx: - printing argv[1] in various places - printing a single 'X' in various places to count how many times we get to different instructions - exiting with the current value of EAX in various places I repeatedly went down the wrong trail in several ways: - forgetting that the problem lay in native runs, and accidentally switching to subx runs during debugging. - forgetting to pass commandline args, because ex10 doesn't check its argv - writing the wrong comment for an instruction, and then miscalculating the set of registers that need to be saved. - forgetting that syscalls clobber EAX. Debugging native runs is hard, because you have to write non-trivial code to instrument the binary, and instrumentation can itself be buggy. When we finally tracked it down, I recognized the problem immediately. I'd meant to confirm the behavior of opcode 8a against bare metal, and then forgot. In any case, opcode 8a was inconsistent with 88. Sloppy.
* 4578 - subx: implement inc/dec operationsKartik Agaram2018-09-211-17/+6
|
* 4547Kartik Agaram2018-09-161-1/+1
|
* 4538Kartik Agaram2018-09-071-2/+2
|
* 4537Kartik Agaram2018-09-071-4/+5
| | | | | | | | | | | | | | | Streamline the factorial function; we don't need to save a stack variable into a register before operating on it. All instructions can take a stack variable directly. In the process we found two bugs: a) Opcode f7 was not implemented correctly. It was internally consistent but I'd never validated it against a natively running program. Turns out it encodes multiple instructions, not just 'not'. b) The way we look up imm32 operands was sometimes reading them before disp8/disp32 operands.
* 4527 - reading commandline argumentsKartik Agaram2018-08-301-1/+60
| | | | | | | | | | | The new example ex9 doesn't yet work natively. In the process I've emulated the kernel's role in providing args, implemented a couple of instructions acting on 8-bit operands (useful for ASCII string operations), and begun the start of the standard library (ascii_length is the same as strlen). At the level of SubX we're just only going to support ASCII.
* 4469Kartik Agaram2018-08-031-0/+589