Add some notes on design choices.

diff --git a/NOTES b/NOTES
new file mode 100644 (file)
index 0000000..a35a2e7
--- /dev/null
+++ b/NOTES
@@ -0,0 +1,50 @@
+Some notes to help clarify things
+---------------------------------
+
+1. Each node in the DSL's expression tree corresponds to a scalar value
+with 0 or more indices.
+
+2. Indices have dependencies on other indices. This will affect the loop
+nesting order.
+
+3. Nodes have dependencies on other nodes. This will affect where in
+loops certain expressions are computed.
+
+4. Nodes that destroy indices imply that information will be passed
+outside a loop. This will typically require allocation of storage.
+
+5. Nodes will currently assume that they get random access to the
+iteration space described by the indices they destroy.
+
+6. Nodes will have a prefix call that is used to set-up any data
+structure they need and iterate over their operands
+
+7. Nodes will have a call that allows access to their data, using their
+already defined indices.
+
+8. Nodes will have a postfix call that performs cleanup of any allocated
+data structures.
+
+Code Generation Strategy
+------------------------
+
+1. Topological traversal of expression tree.
+
+2. Only when nodes destroy an index is the loop for that expression
+created.
+
+3. DataSpaces (leaf nodes) are traversed in their native format.
+
+4. All other iteration spaces will be assumed to be dense, and will
+dynamically allocated memory in the dense format.
+
+5. We would expect that it would be possible to implement an inner
+product as requiring O(1) space if the loops are traversed in the
+correct order. However this requires that the indices that are not being
+reduced over are dense.
+
+In the case of removing a PPD-index, the x, y & z indices are derived
+and also dependent upon the specific PPD.
+
+The correct strategy would appear to be to destroy and re-create any
+indices that are derived (depend?) on the indices being eliminated.