chore: update dist/

dist/docs/glossary/index.html

@@ -33,6 +33,7 @@
 <p>Affordance is what the environment offers the individual that they can readily perceive.</p>
 <p>via <a href="https://en.wikipedia.org/wiki/Affordance">https://en.wikipedia.org/wiki/Affordance</a></p>
 <p>Concurrent::</p>
+  <!-- TODO[seth]: revisit this; "concurrent" doesn't only describe work, but also processes. I stand by there being an important distinction to derive here, though  -->
 <p>Composable independently executable work, i.e. work that is safe to re-order or overlap in execution without changing the outcome.</p>
 <p>See also: parallel; in our usage, concurrency permits simple parallelism, but does not require or even imply it.</p>
 <p>NB: this disagrees with CUDA’s less precise terminology, where they often use “concurrent” and “concurrency” to mean “parallel” and “parallelism,” e.g.</p>
@@ -46,6 +47,12 @@
 <p>Each device has its own default stream […], so commands issued to the default stream of a device may execute out of order or concurrently with respect to commands issued to the default stream of any other device.</p>
 </blockquote>
 <p>We might prefer to say that the fact that different devices have distinct default streams implies work submitted to both queues will be treated <em>concurrently</em> (i.e. as if it were safe to compose without regard to order or overlap) and therefore may run out of order or in parallel with each other.</p>
+<p>Load-Store Architecture::</p>
+<p>A computer architecture where data memory accesses are explicitly restricted to specific load and store instructions, and most operations are presumed to operate solely on registers. Load-store architectures are generally simpler to implement and scale, and vector processors (such as GPUs) are able to side-step many of the downsides by explicitly batching memory accesses in the form of strided vector loads.</p>
+  <!-- TODO[seth]: well, that cutely avoids saying GPUs are load-store, but does it help anyone? -->
+<p>SPIR-V models a load-store architecture, with <code dir="auto">OpLoad</code>/<code dir="auto">OpStore</code> operations that offer indirect access to memory, vs. operations like <code dir="auto">OpAdd</code> that operate directly over previous result values.</p>
+<p>Compare with: register-memory architectures, where most instructions may operate on either memory or registers in either their source or destination positions.</p>
+<p>See also: RISC architecture, as a distinguishing attribute of many RISC processors is that they have relatively few implicit memory access operations compared to their CISC counterparts.</p>
 <p>Parallel::</p>
 <p>Simultaneous execution of work.</p>
 <p>NB: the work may be inter-dependent, i.e. it may not produce the same result (or perhaps even complete at all) if the work is re-ordered or the overlap changes. For example, a process A that launches B, sends a signal, and then waits for B to exit will <em>deadlock</em> if B also waits for that signal and no parallelism exists.</p>

dist/pagefind/pagefind-entry.json

@@ -1 +1 @@
-{"version":"1.1.0","languages":{"en":{"hash":"en_8a50cd4d8e","wasm":"en","page_count":4}}}
+{"version":"1.1.0","languages":{"en":{"hash":"en_8a6591f631","wasm":"en","page_count":4}}}

dist/styles/index.css

@@ -21,15 +21,24 @@ textarea {
 	width : 860px;
 	height : 500px;
 }
-#controls {
+.vis-wip textarea {
+	height: 220px;
+	width : 110px;
+}
+.controls {
   text-align : center;
   background : #ccc;
   padding : .5em 0;
 }
-#controls button {
+.controls select {
+	position: absolute;
+	margin : 0 1em;
+	left: 0;
+}
+.controls button {
   margin : 0 1em;
 }
-#controls div {
+.controls div {
 	padding-top: 0.5em;
 }
 output.stdio {
@@ -88,3 +97,9 @@ nav li:not(:last-child) a::after  {
 	content: " (was: " attr(data-prev) ")";
 	color: lightslategrey;
 }
+.hidden {
+	display: none;
+}
+shadow-root:not(:defined) {
+	display: none;
+}