about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 5220Kartik Agaram2019-05-2211-370/+386
|
* 5219Kartik Agaram2019-05-223-12/+32
| | | | | After fixing bugs, checking alloc_ids now requires 9 instructions rather than 6.
* 5218Kartik Agaram2019-05-2217-9/+9
|
* 5217Kartik Agaram2019-05-222-2/+2
| | | | | | | | Couple of typos in handle.subx. We didn't notice because a missing /r32 field gets turned into 0/EAX anyway, and because ECX happens to have the same value as EAX in the specific test caller. But it's still not running as expected, now that I'm looking closely.
* 5216Kartik Agaram2019-05-222-166/+168
|
* 5215Kartik Agaram2019-05-201-0/+2
|
* 5214 - update app code statsKartik Agaram2019-05-201-4/+9
|
* 5213Kartik Agaram2019-05-202-2/+2
|
* 5212Kartik Agaram2019-05-201-1/+1
|
* 5211Kartik Agaram2019-05-2067-12192/+15345
| | | | Update syntax-highlighted renderings after a _long_ time.
* SubX in SubX: done with dquotes phaseKartik Agaram2019-05-201-0/+10
| | | | Add the new binary to CI.
* Merge branch 'dquotes-3'Kartik Agaram2019-05-203-181/+831
|\
| * clean up a redundant primitiveKartik Agaram2019-05-202-84/+4
| |
| * .Kartik Agaram2019-05-202-6/+6
| |
| * dquotes now doneKartik Agaram2019-05-202-41/+162
| | | | | | | | | | We need yet another helper for computing the lengths of strings, while checking for escape sequences.
| * standardize the loop in skip-string-in-sliceKartik Agaram2019-05-202-5/+8
| | | | | | | | | | | | We're going to be cloning it for the length computation. Anytime we do something non-standard it's invariably short-lived.
| * support string literals in emit-string-literal-dataKartik Agaram2019-05-202-11/+19
| | | | | | | | As expected, almost all tests now passing.
| * .Kartik Agaram2019-05-201-0/+1
| |
| * support string literals in emit-metadataKartik Agaram2019-05-202-10/+31
| |
| * move local variable up following conventionsKartik Agaram2019-05-192-6/+11
| | | | | | | | | | More importantly, don't mix reclaiming locals with discarding args after a call.
| * convention: source arg in ESIKartik Agaram2019-05-192-8/+15
| | | | | | | | I _think_ we'll need to use it below. But may be wrong.
| * handle words with just metadataKartik Agaram2019-05-192-3/+66
| | | | | | | | | | Kind of a pathological case, but makes our loop follow a standard format, and provides some error checking at low cost.
| * minor style tweaks for emit-metadataKartik Agaram2019-05-192-40/+27
| |
| * minor style cleanupKartik Agaram2019-05-181-20/+7
| |
| * skip-string: fix a bug in computing in->readKartik Agaram2019-05-182-4/+48
| | | | | | | | I was missing a test to catch this.
| * minor style cleanupKartik Agaram2019-05-182-34/+17
| | | | | | | | | | | | | | | | | | | | | | | | I like to be able to jump between functions and tests using '}' in Vim :) We also shouldn't put the wrong argument types in the tabular columns. Just make it obvious they're not in use when instructions don't have a ModR/M byte. End-of-line comments are really only useful for instructions with a ModR/M byte.
| * 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
* | 5189Kartik Agaram2019-05-187-0/+0
| | | | | | | | Fix CI.
* | 5188Kartik Agaram2019-05-182-12/+9
| | | | | | | | Clean up some unused constants.
* | 5187Kartik Agaram2019-05-183-2/+3
| | | | | | | | CI should have been failing for a few days. Now fixed.
* | Merge pull request #33 from akkartik/new-segment-headerKartik Agaram2019-05-1842-609/+560
|\ \ | | | | | | New syntax for segment headers
| * | switch to new syntax for segment headers in C++Kartik Agaram2019-05-1836-514/+481
| | |
| * | support the new segment syntax in assort.subxKartik Agaram2019-05-172-51/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now all implemented phases of the SubX translator in SubX support the new syntax: ✓ hex.subx (no changes required) survey.subx (not yet started) ✓ pack.subx (fixed here) ✓ assort.subx ✓ dquotes.subx (has failing tests for other reasons)
| * | another phase that supports the new segment syntaxKartik Agaram2019-05-172-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current state: ✓ hex.subx (no changes required) survey.subx ✓ pack.subx (fixed here) assort.subx ✓ dquotes.subx (has failing tests for other reasons)
| * | start of new syntax for segment headersKartik Agaram2019-05-172-26/+26
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now SubX defines headers with the following syntax: ``` === ... ``` The `...` can be either a numeric address or a name. Numeric addresses are useful for tests where we want to check addresses of individual instructions. Names are useful in real programs where we want to add to a segment in many places. This approach has long seemed a mess. It's hard to explain, and there's a certain amount of historical evolution that led to it that should be irrelevant to comprehend the current state of the codebase. I started out assuming the first segment was always code, before adding the special names 'code' and 'data'. We pretend to support more than two segments but we don't really. To simplify the code and explanation we'll move to a new syntax: ``` === <name> <address> ``` Code will always belong in the special name 'code', but it no longer has to be first. We need to migrate both our SubX-in-SubX phases and the C++ version. The plan is to start from the top down and update bootstrapping phases that've already been built (see commit 5102 for the list of phases). This commit updates pack.subx. Current state: ✓ hex.subx (no changes required) survey.subx ✓ pack.subx (fixed here) assort.subx dquotes.subx
* / 5181Kartik Agaram2019-05-172-0/+20
|/ | | | Test for the bugfix of commit 2f49a27504.
* 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
| | |
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-28 12:11:00 +0000