about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* add a bounds checkKartik Agaram2019-05-182-1/+38
|
* implement skip-string-in-slice and reimplement skip-string in terms of ↵nc2019-05-181-37/+75
| | | | skip-string-in-slice
* implemented skip-stringnc2019-05-181-0/+51
|
* another failing testKartik Agaram2019-05-172-0/+90
| | | | This one should make `emit-metadata` string-aware.
* dquotes: failing tests for parsing string literalsKartik Agaram2019-05-162-0/+284
| | | | Plan: https://github.com/akkartik/mu/commit/d4a244268841e8e912c98f4587095b701aa5c292#commitcomment-33558279
* 5180Kartik Agaram2019-05-1611-44/+25
| | | | | | | Clean up some old TODOs related to our pre-mmap limitations. Also caught another case of using the wrong comparison. When comparing addresses, one must always use unsigned rather than signed jump instructions.
* 5179Kartik Agaram2019-05-161-4/+8
|
* Merge pull request #23 from akkartik/dquotesKartik Agaram2019-05-1524-187/+1401
|\ | | | | SubX in SubX: Transforming uses of string literals
| * Merge pull request #26 from akkartik/dquotes-1Kartik Agaram2019-05-1524-223/+950
| |\ | | | | | | SubX in SubX: Transforming uses of string literals (prerequisite A)
| | * complete the skeleton of dquotes.subxKartik Agaram2019-05-1512-49/+210
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Still some failing tests: - emit-string-literal-data doesn't ignore metadata when computing the length of literal strings - emit-string-literal-data doesn't handle escape sequences One issue doesn't have a failing test: - emit-metadata doesn't handle string literals containing '/' All these open issues involve a common design question: how to parse a 'word' that includes a string literal that may include spaces. For everything else I know words can't contain spaces and datums can't contain slashes. But for string literals things are tougher.
| | * .Kartik Agaram2019-05-151-1/+1
| | |
| | * Merge branch 'dquotes' into dquotes-1Kartik Agaram2019-05-153-69/+132
| | |\ | | |/ | |/|
| * | Merge branch 'master' into dquotesKartik Agaram2019-05-153-69/+132
| |\ \ | |/ / |/| |
* | | 5163Kartik Agaram2019-05-152-11/+27
| | | | | | | | | | | | A few more places with flag corrections.
* | | 5162Kartik Agaram2019-05-151-7/+7
| | |
* | | 5161Kartik Agaram2019-05-151-27/+27
| | |
* | | 5160Kartik Agaram2019-05-153-16/+6
| | |
* | | 5159Kartik Agaram2019-05-151-11/+68
| | | | | | | | | | | | One more instruction where I forgot to update the carry flag.
| | * .Kartik Agaram2019-05-142-9/+9
| | |
| | * fix a stale register value in dquotes.subxKartik Agaram2019-05-142-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | How did things seem to be working until now? - We were saving an address from the stack to stream.read - When we read this address in skip-chars-matching:loop, we used to stop early But now we've moved the stack to a larger address, one where the most significant byte is set. When the stack address now gets to skip-chars-matching:loop, it's treated as a negative number and we proceed through the loop. At which point we try to index into the array using it. No real test to be written to protect against this :(
| | * Merge branch 'dquotes' into dquotes-1Kartik Agaram2019-05-1328-264/+1499
| | |\ | | |/ | |/| | | | | | | dquotes.subx is now segfaulting after this merge. Seems to be trying to use addresses from the old stack.
| * | Merge branch 'master' into dquotesKartik Agaram2019-05-1327-357/+1363
| |\ \ | |/ / |/| |
* | | 5158Kartik Agaram2019-05-131-3/+3
| | |
* | | Merge pull request #31 from akkartik/carry-flagKartik Agaram2019-05-1322-261/+1094
|\ \ \ | | | | | | | | Start computing the Carry Flag (CF) everywhere
| * | | start using the new carry flagKartik Agaram2019-05-1318-60/+96
| | | | | | | | | | | | | | | | | | | | Skimping on tests; the code changes seem pretty trivial. Will this fix CI?!
| * | | flag tests for opcode 3dKartik Agaram2019-05-131-4/+47
| | | |
| * | | .Kartik Agaram2019-05-131-5/+5
| | | |
| * | | .Kartik Agaram2019-05-131-3/+2
| | | |
| * | | .Kartik Agaram2019-05-133-13/+13
| | | |
| * | | flag tests for opcode 2dKartik Agaram2019-05-131-1/+46
| | | |
| * | | flag tests for opcode 81Kartik Agaram2019-05-131-17/+135
| | | |
| * | | flag tests for opcode 05Kartik Agaram2019-05-132-2/+51
| | | |
| * | | .Kartik Agaram2019-05-131-7/+8
| | | |
| * | | flag tests for opcode 3bKartik Agaram2019-05-131-3/+61
| | | |
| * | | .Kartik Agaram2019-05-133-54/+52
| | | | | | | | | | | | | | | | | | | | | | | | 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
| | | |
| * | | .Kartik Agaram2019-05-131-8/+8
| | | |
| * | | flag tests for opcode 03Kartik Agaram2019-05-131-7/+69
| | | |
| * | | .Kartik Agaram2019-05-132-24/+46
| | | | | | | | | | | | | | | | | | | | Make the first instruction described something that doesn't touch flags, so we don't introduce too much complexity all at once.
| * | | carry flag thoroughly tested in layer 13Kartik Agaram2019-05-132-31/+131
| | | | | | | | | | | | | | | | | | | | This is time-consuming mostly for me to come up with example scenarios testing all the different combinations of flags.
| * | | .Kartik Agaram2019-05-132-20/+20
| | | | | | | | | | | | | | | | Correct some confusing log messages.
| * | | CF needs special handling for some arithmetic opsKartik Agaram2019-05-125-86/+248
| | | | | | | | | | | | | | | | Inline some macro definitions.
| * | | .Kartik Agaram2019-05-122-7/+0
| | | | | | | | | | | | | | | | Drop some prints as a first step to straightening things out.
| * | | snapshot of carry flag implementationKartik Agaram2019-05-125-62/+147
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | 5157Kartik Agaram2019-05-112-10/+10
| | | | | | | | | | | | | | | Support allocating more than 0x01000000 bytes (8MB) to a segment in the VM.
* | | 5156 - error-checking on writes to fileKartik Agaram2019-05-119-0/+29
| | | | | | | | | | | | | | | | | | | | | Pretty blunt for now; just abort the entire program on any failure to write. I'm encountering it because I'm somehow treating a stream address as a file descriptor. Maybe mmap is returning addresses below 0x08000000?
* | | 5155 - check for overflow in mmap segmentsKartik Agaram2019-05-112-1/+12
| | |
* | | 5154Kartik Agaram2019-05-118-0/+2
| | | | | | | | | | | | | | | Bugfix: I'd neglected to update the input stream's state when natively writing a stream to file.
* | | 5153Kartik Agaram2019-05-119-95/+215
| | |
* | | 5152 - check for stack underflow/overflow in VMKartik Agaram2019-05-116-22/+33
| | |
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-07-07 10:34:29 +0000