about summary refs log tree commit diff stats
path: root/counters.mu
Commit message (Collapse)AuthorAgeFilesLines
* 4134 - 'input' = 'ingredient'Kartik K. Agaram2017-12-031-2/+2
|
* 4119Kartik K. Agaram2017-11-101-2/+2
| | | | Running example programs after a long time.
* 4089Kartik K. Agaram2017-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clean up how we reclaim local scopes. It used to work like this (commit 3216): 1. Update refcounts of products after every instruction, EXCEPT: a) when instruction is a non-primitive and the callee starts with 'local-scope' (because it's already not decremented in 'return') OR: b) when instruction is primitive 'next-ingredient' or 'next-ingredient-without-typechecking', and its result is saved to a variable in the default space (because it's already incremented at the time of the call) 2. If a function starts with 'local-scope', force it to be reclaimed before each return. However, since locals may be returned, *very carefully* don't reclaim those. (See the logic in the old `escaping` and `should_update_refcount` functions.) However, this approach had issues. We needed two separate commands for 'local-scope' (reclaim locals on exit) and 'new-default-space' (programmer takes charge of reclaiming locals). The hard-coded reclamation duplicated refcounting logic. In addition to adding complexity, this implementation failed to work if a function overwrites default-space after setting up a local-scope (the old default-space is leaked). It also fails in the presence of continuations. Calling a continuation more than once was guaranteed to corrupt memory (commit 3986). After this commit, reclaiming local scopes now works like this: Update refcounts of products for every PRIMITIVE instruction. For non-primitive instructions, all the work happens in the `return` instruction: increment refcount of ingredients to `return` (unless -- one last bit of ugliness -- they aren't saved in the caller) decrement the refcount of the default-space use existing infrastructure for reclaiming as necessary if reclaiming default-space, first decrement refcount of each local again, use existing infrastructure for reclaiming as necessary This commit (finally!) completes the bulk[1] of step 2 of the plan in commit 3991. It was very hard until I gave up trying to tweak the existing implementation and just test-drove layer 43 from scratch. [1] There's still potential for memory corruption if we abuse `default-space`. I should probably try to add warnings about that at some point (todo in layer 45).
* 4001Kartik K. Agaram2017-09-181-1/+1
|
* 3394Kartik K. Agaram2016-09-171-5/+5
|
* 3390Kartik K. Agaram2016-09-171-5/+5
|
* 3389Kartik K. Agaram2016-09-171-5/+5
|
* 3380Kartik K. Agaram2016-09-171-4/+4
| | | | | One more place we were missing expanding type abbreviations: inside container definitions.
* 3302Kartik K. Agaram2016-09-071-1/+0
|
* 2864 - replace all address:shared with just addressKartik K. Agaram2016-04-241-5/+5
| | | | | | | Now that we no longer have non-shared addresses, we can just always track refcounts for all addresses. Phew!
* 2735 - define recipes using 'def'Kartik K. Agaram2016-03-081-7/+5
| | | | | | | | | | | | I'm dropping all mention of 'recipe' terminology from the Readme. That way I hope to avoid further bike-shedding discussions while I very slowly decide on the right terminology with my students. I could be smarter in my error messages and use 'recipe' when code uses it and 'function' otherwise. But what about other words like ingredient? It would all add complexity that I'm not yet sure is worthwhile. But I do want separate experiences for veteran programmers reading about Mu on github and for people learning programming using Mu.
* 2576 - distinguish allocated addresses from othersKartik K. Agaram2016-01-191-5/+5
| | | | | | | | | | | | | | | | This is the one major refinement on the C programming model I'm planning to introduce in mu. Instead of Rust's menagerie of pointer types and static checking, I want to introduce just one new type, and use it to perform ref-counting at runtime. So far all we're doing is updating new's interface. The actual ref-counting implementation is next. One implication: I might sometimes need duplicate implementations for a recipe with allocated vs vanilla addresses of the same type. So far it seems I can get away with just always passing in allocated addresses; the situations when you want to pass an unallocated address to a recipe should be few and far between.
* 2325Kartik K. Agaram2015-10-301-2/+1
|
* 2324 - static dispatch works with arcane headers!Kartik K. Agaram2015-10-291-8/+7
|
* 2295 - drop first-class recipes and continuationsKartik K. Agaram2015-10-281-8/+8
| | | | Making life too complex at this time.
* 2294Kartik K. Agaram2015-10-281-8/+8
| | | | Bah, sick of CALL and continuations.
* 1880 - switch .mu files to new type-deducing idiomKartik K. Agaram2015-07-291-6/+6
|
* 1868 - start using naked literals everywhereKartik K. Agaram2015-07-281-6/+6
| | | | First step to reducing typing burden. Next step: inferring types.
* 1780 - now we always reclaim local scopesKartik K. Agaram2015-07-131-2/+2
| | | | | | But still no difference in either memory footprint or in running time. This will teach me -- for the umpteenth time -- to optimize before measuring.
* 1773 - update all mu recipes to new-default-spaceKartik K. Agaram2015-07-131-2/+2
| | | | | Turns out to not affect memory utilization or run-time. At all. But still looks nicer and requires less fudging on our part.
* 1599Kartik K. Agaram2015-06-191-4/+4
|
* 1469Kartik K. Agaram2015-05-261-6/+6
|
* 1363 - rename 'integer' to 'number'Kartik K. Agaram2015-05-131-7/+7
| | | | ..now that we support non-integers.
* 1345Kartik K. Agaram2015-05-111-3/+6
|
* 1298 - better ingredient/product handlingKartik K. Agaram2015-05-071-5/+1
| | | | | | | | | | | | | | | | | | | All primitives now always write to all their products. If a product is not used that's fine, but if an instruction seems to expect too many products mu will complain. In the process, many primitives can operate on more than two ingredients where it seems intuitive. You can add or divide more than two numbers together, copy or negate multiple corresponding locations, etc. There's one remaining bit of ugliness. Some instructions like get/get-address, index/index-address, wait-for-location, these can unnecessarily load values from memory when they don't need to. Useful vim commands: %s/ingredients\[\([^\]]*\)\]/ingredients.at(\1)/gc %s/products\[\([^\]]*\)\]/products.at(\1)/gc .,$s/\[\(.\)]/.at(\1)/gc
* 1276 - make C++ version the defaultKartik K. Agaram2015-05-051-30/+32
| | | | I've tried to update the Readme, but there are at least a couple of issues.
* 690 - convention: '$' commands for debugging onlyKartik K. Agaram2015-02-011-3/+3
| | | | | | Swap printing generalized objects using arc's infrastructure to be the $-prefixed debug helper, while the erstwhile $print-key-to-host becomes the primitive print-character to host.
* 578 - switch to non-polymorphic 'print' functionsKartik K. Agaram2015-01-171-2/+2
| | | | | Also clean up various prints from last few commits. As a convention, for debugging we always print directly to host.
* 574 - printing string literals is a hack; hard-code it in for nowKartik K. Agaram2015-01-161-3/+3
|
* 571 - screen primitives take an explicit terminalKartik K. Agaram2015-01-151-5/+5
| | | | | | | | | | | | | | | | | This will let me swap in a fake in tests. Still hacky, though. I'm sure I'm not managing the parameter right in the chessboard app. And then there's the question of whether it should also appear as an output operand. But it's a start. And using nil to mean 'real' is a reasonable convention. If I ever need to handle multiple screens perhaps we'll have to switch to 1:literal/terminal and 2:literal/terminal, etc. But those are equally easy to guard on.
* 498 - how mu provides closuresKartik K. Agaram2015-01-021-1/+1
|
* 497 - strengthen the concept of 'space'Kartik K. Agaram2015-01-021-0/+33
'default-scope' is now 'default-space' 'closure-generator' is now 'next-space-generator' The connection to high-level syntax for closures is now tenuous, so we'll call the 'outer scope' the 'next space'. So, let's try to create a few sentences with all these related ideas: Names map to addresses offset from a default-space when it's provided. Spaces can be strung together. The zeroth variable points to the next space, the one that is accessed when a variable has /space:1. To map a name to an address in the next space, you need to know what function generated that space. A corollary is that the space passed in to a function should always be generated by a single function. Spaces can be used to construct lexical scopes and objects.