| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | 4591 | Kartik Agaram | 2018-09-22 | 1 | -2/+2 |
| | | |||||
| * | 4585 | Kartik Agaram | 2018-09-21 | 1 | -72/+0 |
| | | |||||
| * | 4584 - discrepancy between SubX and native x86 | Kartik Agaram | 2018-09-21 | 1 | -1/+76 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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. | ||||
| * | 4583 | Kartik Agaram | 2018-09-21 | 1 | -1/+1 |
| | | |||||
| * | 4581 | Kartik Agaram | 2018-09-21 | 1 | -1/+1 |
| | | | | | | | | | | | | | Even more cuddling. We want to keep lines short where the opcode and operands are self-explanatory. If there are any implicit registers, etc., we'll continue to do the table layout. The first two columns look messy now; let's see how this goes. Maybe I'll give up on the tabular layout altogether, just string args with a single space. | ||||
| * | 4579 | Kartik Agaram | 2018-09-21 | 1 | -0/+67 |
| New example program: ascii null-terminated string comparison I'd hoped this would be a stepping stone to supporting general ascii comparison, but we're planning to use size-prefixed rather than null-terminated arrays everywhere. The only exception is commandline arguments, which will remain null-terminated to interoperate with Linux. So I'm going to need separate functions for "compare with argv" and for general string comparison. | |||||