From 91624dbacabd0b437bbcce3fdb3dc8e67f577fa6 Mon Sep 17 00:00:00 2001 From: Kartik Agaram Date: Mon, 9 Dec 2019 01:32:48 -0800 Subject: 5807 --- html/031transforms.cc.html | 123 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 html/031transforms.cc.html (limited to 'html/031transforms.cc.html') diff --git a/html/031transforms.cc.html b/html/031transforms.cc.html new file mode 100644 index 00000000..2589975b --- /dev/null +++ b/html/031transforms.cc.html @@ -0,0 +1,123 @@ + + + + +Mu - 031transforms.cc + + + + + + + + + + +https://github.com/akkartik/mu/blob/master/031transforms.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