From 91624dbacabd0b437bbcce3fdb3dc8e67f577fa6 Mon Sep 17 00:00:00 2001 From: Kartik Agaram Date: Mon, 9 Dec 2019 01:32:48 -0800 Subject: 5807 --- html/029transforms.cc.html | 123 --------------------------------------------- 1 file changed, 123 deletions(-) delete mode 100644 html/029transforms.cc.html (limited to 'html/029transforms.cc.html') diff --git a/html/029transforms.cc.html b/html/029transforms.cc.html deleted file mode 100644 index 266332f9..00000000 --- a/html/029transforms.cc.html +++ /dev/null @@ -1,123 +0,0 @@ - - - - -Mu - 029transforms.cc - - - - - - - - - - -https://github.com/akkartik/mu/blob/master/029transforms.cc -
- 1 //: Ordering transforms is a well-known hard problem when building compilers.
- 2 //: In our case we also have the additional notion of layers. The ordering of
- 3 //: layers can have nothing in common with the ordering of transforms when
- 4 //: SubX is tangled and run. This can be confusing for readers, particularly
- 5 //: if later layers start inserting transforms at arbitrary points between
- 6 //: transforms introduced earlier. Over time adding transforms can get harder
- 7 //: and harder, having to meet the constraints of everything that's come
- 8 //: before. It's worth thinking about organization up-front so the ordering is
- 9 //: easy to hold in our heads, and it's obvious where to add a new transform.
-10 //: Some constraints:
-11 //:
-12 //:   1. Layers force us to build SubX bottom-up; since we want to be able to
-13 //:   build and run SubX after stopping loading at any layer, the overall
-14 //:   organization has to be to introduce primitives before we start using
-15 //:   them.
-16 //:
-17 //:   2. Transforms usually need to be run top-down, converting high-level
-18 //:   representations to low-level ones so that low-level layers can be
-19 //:   oblivious to them.
-20 //:
-21 //:   3. When running we'd often like new representations to be checked before
-22 //:   they are transformed away. The whole reason for new representations is
-23 //:   often to add new kinds of automatic checking for our machine code
-24 //:   programs.
-25 //:
-26 //: Putting these constraints together, we'll use the following broad
-27 //: organization:
-28 //:
-29 //:   a) We'll divide up our transforms into "levels", each level consisting
-30 //:   of multiple transforms, and dealing in some new set of representational
-31 //:   ideas. Levels will be added in reverse order to the one their transforms
-32 //:   will be run in.
-33 //:
-34 //:     To run all transforms:
-35 //:       Load transforms for level n
-36 //:       Load transforms for level n-1
-37 //:       ...
-38 //:       Load transforms for level 2
-39 //:       Run code at level 1
-40 //:
-41 //:   b) *Within* a level we'll usually introduce transforms in the order
-42 //:   they're run in.
-43 //:
-44 //:     To run transforms for level n:
-45 //:       Perform transform of layer l
-46 //:       Perform transform of layer l+1
-47 //:       ...
-48 //:
-49 //:   c) Within a level it's often most natural to introduce a new
-50 //:   representation by showing how it's transformed to the level below. To
-51 //:   make such exceptions more obvious checks usually won't be first-class
-52 //:   transforms; instead code that keeps the program unmodified will run
-53 //:   within transforms before they mutate the program. As an example:
-54 //:
-55 //:     Layer l introduces a transform
-56 //:     Layer l+1 adds precondition checks for the transform
-57 //:
-58 //: This may all seem abstract, but will hopefully make sense over time. The
-59 //: goals are basically to always have a working program after any layer, to
-60 //: have the order of layers make narrative sense, and to order transforms
-61 //: correctly at runtime.
-62 
-63 :(before "End One-time Setup")
-64 // Begin Transforms
-65 // End Transforms
-
- - - -- cgit 1.4.1-2-gfad0