7842 - new directory organization

Baremetal is now the default build target and therefore has its sources
at the top-level. Baremetal programs build using the phase-2 Mu toolchain
that requires a Linux kernel. This phase-2 codebase which used to be at
the top-level is now under the linux/ directory. Finally, the phase-2 toolchain,
while self-hosting, has a way to bootstrap from a C implementation, which
is now stored in linux/bootstrap. The bootstrap C implementation uses some
literate programming tools that are now in linux/bootstrap/tools.

So the whole thing has gotten inverted. Each directory should build one
artifact and include the main sources (along with standard library). Tools
used for building it are relegated to sub-directories, even though those
tools are often useful in their own right, and have had lots of interesting
programs written using them.

A couple of things have gotten dropped in this process:
  - I had old ways to run on just a Linux kernel, or with a Soso kernel.
    No more.
  - I had some old tooling for running a single test at the cursor. I haven't
    used that lately. Maybe I'll bring it back one day.

The reorg isn't done yet. Still to do:
  - redo documentation everywhere. All the README files, all other markdown,
    particularly vocabulary.md.
  - clean up how-to-run comments at the start of programs everywhere
  - rethink what to do with the html/ directory. Do we even want to keep
    supporting it?

In spite of these shortcomings, all the scripts at the top-level, linux/
and linux/bootstrap are working. The names of the scripts also feel reasonable.
This is a good milestone to take stock at.

1 files changed, 16 insertions, 0 deletions

diff --git a/linux/300.txt b/linux/300.txt
new file mode 100644
index 00000000..62413330
--- /dev/null
+++ b/linux/300.txt
@@ -0,0 +1,16 @@
+Layers in the 3xx series use all the available syntax sugar for SubX programs.
+Functions here can be called from Mu programs if they meet certain criteria:
+
+  - There's a signature for them in 400.mu
+  - Inouts on the stack, outputs in registers
+  - Valid Mu types everywhere (Mu's type system isn't expressive enough for
+    everything SubX does in rare situations.)
+  - No way to for an `addr` to escape a function. No `(... addr ... addr ...)`
+    inouts, and no `(... addr ...)` outputs.
+
+While functions _can_ be called, not all SubX functions meeting these criteria
+_should_ be called. In particular, avoid exporting functions that could be
+misused. A classic example is trying to add a `size-of` operator. If you're
+doing that you're likely going to rely on programmers to use it correctly. Mu
+tries to be idiot-proof. Even if SubX requires greater care, using SubX
+primitives from Mu should not.