Changeset d3942b9 for doc

Timestamp:

Oct 21, 2024, 12:34:46 PM (4 days ago)

Author:

Michael Brooks <mlbrooks@…>

Branches:

master

Children:

42d81a7

Parents:

187be97

Message:

Thesis, array, C typing rules, add discussion dimension hoisting.

File:

• doc/theses/mike_brooks_MMath/array.tex (modified) (1 diff)

doc/theses/mike_brooks_MMath/array.tex

@@ -504 +504 @@
 TODO: summarize the C rules and add the case-comparison table
 
-TODO: Discuss Recourse
-
-TODO: Discuss dimension hoisting, which addresses the challenge of extra unification for cost calculation
+The conservatism of the new rule set can leave a programmer needing a recourse,
+when needing to use a dimension expression whose stability argument
+is more subtle than current-state analysis.
+This recourse is to declare an explicit constant for the dimension value.
+Consider these two dimension expressions,
+whose reuses are rejected by the blunt current-state rules:
+\begin{cfa}
+        void f( int & nr, const int nv ) {
+                float x[nr];
+                float (*xp)[nr] = & x; // reject: nr varying (no references)
+                float y[nv + 1];
+                float (*yp)[nv + 1] = & y; // reject: ?+? unpredicable (no functions)
+        }
+\end{cfa}
+Yet, both dimension expressions are reused safely.
+(The @nr@ reference is never written, not volatile
+and control does not leave the function between the uses.
+The name @?+?@ resolves to a function that is quite predictable.)
+The programmer here can add the constant declarations:
+\begin{cfa}
+        void f( int & nr, const int nv ) {
+                @const int nx@ = nr;
+                float x[nx];
+                float (*xp)[nx] = & x; // acept
+                @const int ny@ = nv + 1;
+                float y[ny];
+                float (*yp)[ny] = & y; // accept
+        }
+\end{cfa}
+The result is the originally intended semantics,
+achieved by adding a superfluous ``snapshot it as of now'' directive.
+
+The snapshotting trick is also used by the translation, though to achieve a different outcome.
+Rather obviously, every array must be subscriptable, even a bizzarre one:
+\begin{cfa}
+        array( float, rand(10) ) x;
+        x[0];  // 10% chance of bound-check failure
+\end{cfa}
+Less obvious is that the mechanism of subscripting is a function call,
+which must communicate length accurately.
+The bound-check above (callee logic) must use the actual allocated length of @x@,
+without mistakenly reevaluating the dimension expression, @rand(10)@.
+Adjusting the example to make the function's use of length more explicit:
+\begin{cfa}
+        forall ( T * )
+        void f( T * x ) { sout | sizeof(*x); }
+        float x[ rand(10) ];
+        f( x );
+\end{cfa}
+Considering that the partly translated function declaration is, loosely,
+\begin{cfa}
+        void f( size_t __sizeof_T, void * x ) { sout | __sizeof_T; }
+\end{cfa}
+the translated call must not go like:
+\begin{cfa}
+        float x[ rand(10) ];
+        f( rand(10), &x );
+\end{cfa}
+Rather, its actual translation is like:
+\begin{cfa}
+        size_t __dim_x = rand(10);
+        float x[ __dim_x ];
+        f( __dim_x, &x );
+\end{cfa}
+The occurrence of this dimension hoisting during translation was present in the preexisting \CFA compiler.
+But its cases were buggy, particularly with determining, ``Can hoisting be skipped here?''
+For skipping this hoisting is clearly desirable in some cases,
+not the least of which is when the programmer has already done so manually.
+My work includes getting these cases right, harmonized with the accept/reject criteria, and tested.
+
+
+
+TODO: Discuss the interaction of this dimension hoisting with the challenge of extra unification for cost calculation
 
 \section{Multidimensional Arrays}