about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* .Kartik Agaram2019-06-089-22/+17
| | | | Simplify `string-equal`.
* implement compute-widthnc2019-06-082-270/+357
|
* added tests for compute-widthnc2019-06-081-0/+112
|
* start fleshing out trace support some moreKartik Agaram2019-06-058-5/+23
| | | | | I think the path to readable tests for survey.subx passes through white-box tests.
* .Kartik Agaram2019-05-2712-136/+143
| | | | | | 'get-or-insert-stream' is now the more generic 'get-or-insert' that can handle tables of any value type. But callers have to be careful to cast values to the right type.
* .Kartik Agaram2019-05-266-385/+278
|
* new primitive: check-array-equalKartik Agaram2019-05-268-0/+68
|
* new primitive: parse-array-of-intsKartik Agaram2019-05-2514-8/+355
| | | | | | | | | | Mostly for tests. For every new type we want to compare in a test, we're now going to start using some primitive that can parse its value from string. In this manner we can get syntax for literals in machine code. Open question: parsing aggregates of aggregates. Like an array of structs. This is the first time we allocate from the heap in standard library tests. So we now need to start initializing the heap in all our apps.
* .Kartik Agaram2019-05-2511-18/+17
| | | | | hoist 'Heap' variable into the std library in anticipation of the parse-array-of-ints primitive.
* new primitive: array-equal?Kartik Agaram2019-05-258-0/+247
|
* new primitive for tests: check-string-equalKartik Agaram2019-05-258-0/+53
|
* .Kartik Agaram2019-05-252-1/+2
|
* .Kartik Agaram2019-05-241-7/+6
|
* .Kartik Agaram2019-05-201-0/+0
|
* .Kartik Agaram2019-05-191-0/+6
| | | | add lengths to data blobs
* initial skeleton for survey.subxKartik Agaram2019-05-182-0/+297
| | | | | | | | Start of the final phase needed to implement SubX in SubX: $ cat files.subx ... |dquotes |assort |pack |survey |hex > a.elf survey.subx is responsible for assigning addresses to labels and segments.
* 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
| | |
* | | 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
| | | |