21 files changed, 306 insertions, 278 deletions

diff --git a/README.txt b/README.txt
index 55ba61b..ce7a254 100644
--- a/README.txt
+++ b/README.txt
@@ -129,7 +129,8 @@ lexer feature for that sort of thing. Evocation doesn't do that, because
 eventually fancy syntax and grammar will be implemented at a higher layer,
 using the experimental parsing formalism that doesn't exist yet. If you want
 to see where this feature would be if it were implemented in the simpler way,
-you can read the definition of the word named "word", in interpret.e.
+you can read the definition of the word named "word", in
+language/dynamic/interpret.e.
 
   If you went to look at that and you're wondering: Yeah, Evocation's lexer
 really is that short and simple. Part of why it's able to be that easy is that
@@ -207,45 +208,47 @@ evoke.e. It's really short, and worth a quick glance right now. It lists all
 the other source files and the order they get loaded in and how they're
 processed.
 
-  The files that do the work to make Evocation run at all are execution.e and
-core.e. It's worth reading through both of them slowly. After you've read
-core.e, you'll know a lot of basic words that can be used as commands within
-Evocation.
+  The files that do the work to make Evocation run at all are
+compilation/execution.e and language/static/core.e. It's worth reading through
+both of them slowly. After you've read core.e, you'll know a lot of basic
+words that can be used as commands within Evocation.
 
   A lot of Evocation is written in Evocation's version of assembly language.
-The file amd64.e is the one that implements all the assembly instructions.
-Writing a real program in assembly also requires resolving labels, which are
-a special syntax that gives names to addresses. The behavior of labels is all
-implemented in labels.e.
-
-  On the assembly language front, there's also linux.e which contains assembly
-words for doing things specific to the Linux operating system, such as reading
-input, and there's elf.e which contains words for outputting the special file
-headers that let the operating system understand that a file is an executable
-program.
-
-  In terms of the Forth-y bits, input.e and output.e are concerned with
-getting text into and out of the language. The infrastructure to define words
-is in dynamic.e, and the syntax for it is in interpret.e. The high-level flow
-control words are in flow-control.e. Some of the features of execution.e had
-to be separated out into their own file, because of details about how the
-compiler works; that stuff is in execution-suport.e.
+The file language/static/amd64.e is the one that implements all the assembly
+instructions. Writing a real program in assembly also requires resolving
+labels, which are a special syntax that gives names to addresses. The behavior
+of labels is all implemented in compilation/labels.e.
+
+  On the assembly language front, there's also language/static/linux.e which
+contains assembly words for doing things specific to the Linux operating
+system, such as reading input, and there's compilation/elf.e which contains
+words for outputting the special file headers that let the operating system
+understand that a file is an executable program.
+
+  In terms of the Forth-y bits, language/dynamic/input.e and
+language/static/output.e are concerned with getting text into and out of the
+language. The infrastructure to define words is in language/dynamic/dynamic.e,
+and the syntax for it is in language/dynamic/interpret.e. The high-level flow
+control words are in language/dynamic/flow-control.e. Some of the features of
+compilation/execution.e had to be separated out into their own file, because
+of details about how the compiler works; that stuff is in
+language/static/execution-suport.e.
 
   So, there's all those relatively normal compiler internals in those various
 files, which are all fairly self-contained... and then there's the
 transformation facility. This is Evocation's most unique architectural
-decision, and it's in transform.e. It's well documented, but it's also
-extremely conceptually dense. Feel free to give it a skim, that's the only way
-to build familiarity with these things, but you should probably have a solid
-understanding of the rest of the internals before you place any high
+decision, and it's in compilation/transform.e. It's well documented, but it's
+also extremely conceptually dense. Feel free to give it a skim, that's the
+only way to build familiarity with these things, but you should probably have
+a solid understanding of the rest of the internals before you place any high
 expectations on yourself around understanding the transformation facility.
 
   It's okay, you can benefit from it before you understand it: Transformation
 provides the core tricks that make it possible to compile Forth code into
 standalone executables. The call to label-transform in evoke.e, and the call
-to log-load-transform in execution.e, are the two spots where compilation is
-handed off to the transformation facility, and you can pretty much just take
-it for granted that it works, until you feel ready.
+to log-load-transform in compilation/execution.e, are the two spots where
+compilation is handed off to the transformation facility, and you can pretty
+much just take it for granted that it works, until you feel ready.
 
   If you want examples of programs that are smaller than Evocation itself,
 quine.e is a tiny program written in proper Evocation that outputs its own
@@ -305,13 +308,13 @@ created.
 
   The binary bootstrapping strategy rests on something called the
 "hex transform", the most complex of the transformations provided as part of
-Evocation's transformation facility in transform.e. The hex transform has the
-task of transforming an entire compilation process, which would otherwise
-produce an executable binary, and instead output a commented hex dump of that
-binary which describes its internals and their purpose, byte by byte, in
-sufficient detail to allow a human reader to audit their correctness. It will
-do this by passing through comments and call-stack information from the
-compilation process to the resulting output.
+Evocation's transformation facility in compilation/transform.e. The hex
+transform has the task of transforming an entire compilation process, which
+would otherwise produce an executable binary, and instead output a commented
+hex dump of that binary which describes its internals and their purpose, byte
+by byte, in sufficient detail to allow a human reader to audit their
+correctness. It will do this by passing through comments and call-stack
+information from the compilation process to the resulting output.
 
   In order to turn this commented hex dump into a binary, there is a tiny
 program called "hex" which handles comments in Evocations ~ syntax, and
@@ -359,8 +362,8 @@ do in the  near future, now that bootstrapping is complete.
   Nearly all of this runtime is attributable to the log-load transform; if
 you're working on something that doesn't involve the log-load transform, you
 may find it useful to temporarily comment out the call to log-load-transform
-in execution.e, replacing it with two invocations of drop. This will not
-produce a working compiler, but it will finish faster.
+in compilation/execution.e, replacing it with two invocations of drop. This
+will not produce a working compiler, but it will finish faster.
 
   Now get debugging! :)
 
diff --git a/elf.e b/compilation/elf.e
index 2a67c54..f39a1a0 100644
--- a/elf.e
+++ b/compilation/elf.e
@@ -6,12 +6,12 @@
 ~ do a lot of ELF-specific stuff to ensure that our output is in a format
 ~ Linux knows how to run.
 ~
-~   This relies on the label facility defined in labels.e. Make sure to load
-~ that first.
+~   This relies on the label facility defined in compilation/labels.e. Make
+~ sure to load that first.
 ~
 ~   This file makes use of magic comments for the hex transform, described in
-~ detail in transform.e, but its use is trivial and doesn't require accounting
-~ conventions.
+~ detail in compilation/transform.e, but its use is trivial and doesn't
+~ require accounting conventions.
 
 ~ ~~~~~~~~~~~~~~~~~~~~~
 ~ ~~ ELF file header ~~
diff --git a/execution.e b/compilation/execution.e
index 81ec03b..ecf5ec4 100644
--- a/execution.e
+++ b/compilation/execution.e
@@ -146,7 +146,8 @@
 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 ~   The macros next, beforenext, pushcontrol, and popcontrol are implemented
-~ in execution-support.e. It's a good idea to go read about them now.
+~ in language/static/execution-support.e. It's a good idea to go read about
+~ them now.
 ~
 ~ TODO the following high-level summary should go... somewhere?
 ~   When a docol word is invoked, it immediately does pushcontrol (see
@@ -488,7 +489,7 @@
   ~ entire program and be easy to find from any code within it, we need to
   ~ do something else. Anyway, since we have the address, we can use it for
   ~ the next little bit of setup. We have a bunch of helper words, from
-  ~ log-load.e, which make this easier.
+  ~ language/static/log-load.e, which make this easier.
   ~
   ~   The first few words we define are our variables, which hardcode the
   ~ addresses they will return - but since we're doing this at runtime,
@@ -586,7 +587,7 @@
 ~ ~~~~~~~~~~~
 ~
 ~   The definitions of "docol" and "exit" are very tightly bound up with the
-~ execution model. They're defined and explained in core.e, because they need
-~ to be part of the build process in two different ways, like the other core
-~ functionality.
+~ execution model. They're defined and explained in language/static/core.e,
+~ because they need to be part of the build process in two different ways,
+~ like the other core functionality.
 
diff --git a/labels.e b/compilation/labels.e
index 6ac26b2..2a02a4c 100644
--- a/labels.e
+++ b/compilation/labels.e
@@ -270,8 +270,8 @@
 ~      -- output start, current output pointer)
 ~
 ~   In general, this is the same interface that code generation words should
-~ use to communicate with each other. For example, all the words in elf.e
-~ use this interface.
+~ use to communicate with each other. For example, all the words in
+~ compilation/elf.e use this interface.
 ~
 ~ (execution token -- output start, output length)
 : label-loop
diff --git a/transform.e b/compilation/transform.e
index 4c550e1..80ef98b 100644
--- a/transform.e
+++ b/compilation/transform.e
@@ -14,7 +14,7 @@
 ~ log-load transform, each of which takes a string containing Evocation source
 ~ code and produces compiled code that has been modified to operate in a
 ~ specific way. The transforms rely on the label facility provided by
-~ labels.e, and expect to run from within label-loop.
+~ compilation/labels.e, and expect to run from within label-loop.
 ~
 ~   The label transform produces code that uses one label per word it defines,
 ~ to statically reference everything. Thus, when output to an executable
@@ -60,7 +60,7 @@
 ~ corresponding label whose value is the offset of its codeword, and it causes
 ~ all compiled invocations of other words to be resolved by using these labels.
 ~ The label transform is suitable for code that must be directly invoked by
-~ the warm-start routine provided by execution.e.
+~ the warm-start routine provided by compilation/execution.e.
 ~
 ~   The most fundamental technique the label transform performs is to separate
 ~ words that run in compile mode from words that run immediately.  There is no
@@ -126,14 +126,15 @@
 ~ produces a compiled routine which, when run, appends the original code to
 ~ the log. As the routine is run, each reference to another word is resolved
 ~ by looking up the name of the target word in the log. Furthermore, these
-~ lookups are done using log-load-find, defined in log-load.e, which accepts
-~ a pointer to the log's base address as a parameter. See that file for more
-~ explanation of what the log is and why it's important. Thus, unlike normal
-~ accesses to the log, this routine doesn't rely on already having the log's
-~ base address hardcoded into it at the time of its own compilation. The
-~ log-load transform is suitable for implementing the core responsibilities of
-~ the warm-start routine provided by execution.e, relying on only a few
-~ specific words that it statically references via labels.
+~ lookups are done using log-load-find, defined in language/static/log-load.e,
+~ which accepts a pointer to the log's base address as a parameter. See that
+~ file for more explanation of what the log is and why it's important. Thus,
+~ unlike normal accesses to the log, this routine doesn't rely on already
+~ having the log's base address hardcoded into it at the time of its own
+~ compilation. The log-load transform is suitable for implementing the core
+~ responsibilities of the warm-start routine provided by
+~ compilation/execution.e, relying on only a few specific words that it
+~ statically references via labels.
 ~
 ~   Much like the label transform, the log-load transform provides alternate
 ~ versions of certain immediate words used in word definition. Also like the
@@ -331,12 +332,12 @@ allocate-transformation-state s" transformation-state" variable
 ~ log address as the only value on the stack when it begins, and any time it
 ~ does something that requires looking at the log, it needs to be able to find
 ~ that address. The log-load routine runs as part of the warm-start routine
-~ (see execution.e), whose overall job is to get Evocation into a state where
-~ it can freely work with dynamically-allocated data on the log whose address
-~ isn't known at compile time. Therefore, necessarily, the log-load routine
-~ itself cannot assume access to any scratch space; the value stack is the
-~ only place it can store anything it needs, most crucially including the log
-~ address.
+~ (see compilation/execution.e), whose overall job is to get Evocation into a
+~ state where it can freely work with dynamically-allocated data on the log
+~ whose address isn't known at compile time. Therefore, necessarily, the
+~ log-load routine itself cannot assume access to any scratch space; the value
+~ stack is the only place it can store anything it needs, most crucially
+~ including the log address.
 ~
 ~   Fortunately, it is possible for the transform's own generated code to
 ~ cooperate with the transformed code so that they can both share the stack,
@@ -355,7 +356,7 @@ allocate-transformation-state s" transformation-state" variable
 ~
 ~ (name pointer -- delta value)
 : transform-get-stack-delta
-  ~ From core.e.
+  ~ From language/static/core.e.
   dup s" docol" stringcmp 0 = { drop 1 exit } if
   dup s" exit" stringcmp 0 = { drop 0 exit } if
   dup s" swap" stringcmp 0 = { drop 0 exit } if
@@ -443,12 +444,12 @@ allocate-transformation-state s" transformation-state" variable
   dup s" negate" stringcmp 0 = { drop 0 exit } if
   dup s" align-floor" stringcmp 0 = { drop -1 exit } if
 
-  ~ From linux.e.
+  ~ From language/static/linux.e.
   dup s" sys-exit" stringcmp 0 = { drop -1 exit } if
   dup s" sys-write" stringcmp 0 = { drop -2 exit } if
   dup s" sys-read" stringcmp 0 = { drop -2 exit } if
 
-  ~ From output.e.
+  ~ From language/static/output.e.
   dup s" emitstring" stringcmp 0 = { drop -1 exit } if
   dup s" space" stringcmp 0 = { drop 0 exit } if
   dup s" newline" stringcmp 0 = { drop 0 exit } if
@@ -465,7 +466,7 @@ allocate-transformation-state s" transformation-state" variable
   dup s" .hex64" stringcmp 0 = { drop -1 exit } if
   dup s" .hexn" stringcmp 0 = { drop -2 exit } if
 
-  ~ From amd64.e.
+  ~ From language/static/amd64.e.
   dup s" :rax" stringcmp 0 = { drop 1 exit } if
   dup s" :rcx" stringcmp 0 = { drop 1 exit } if
   dup s" :rdx" stringcmp 0 = { drop 1 exit } if
@@ -669,13 +670,13 @@ allocate-transformation-state s" transformation-state" variable
   dup s" jmp-rel-imm8" stringcmp 0 = { drop -1 exit } if
   dup s" jmp-rel-imm32" stringcmp 0 = { drop -1 exit } if
 
-  ~ From execution-support.e.
+  ~ From language/static/execution-support.e.
   dup s" pack-next" stringcmp 0 = { drop 0 exit } if
   dup s" pack-beforenext" stringcmp 0 = { drop -1 exit } if
   dup s" pack-pushcontrol" stringcmp 0 = { drop -1 exit } if
   dup s" pack-popcontrol" stringcmp 0 = { drop -1 exit } if
 
-  ~ From dynamic.e.
+  ~ From language/dynamic/dynamic.e.
   dup s" stack" stringcmp 0 = { drop 0 exit } if
   dup s" stackhex" stringcmp 0 = { drop 0 exit } if
   dup s" is-in-log" stringcmp 0 = { drop 0 exit } if
@@ -717,7 +718,7 @@ allocate-transformation-state s" transformation-state" variable
   dup s" keyword" stringcmp 0 = { drop -1 exit } if
   dup s" literal" stringcmp 0 = { drop -1 exit } if
 
-  ~ From input.e.
+  ~ From language/dynamic/input.e.
   dup s" buffer-physical-start" stringcmp 0 = { drop 0 exit } if
   dup s" buffer-physical-length" stringcmp 0 = { drop 0 exit } if
   dup s" buffer-logical-start" stringcmp 0 = { drop 0 exit } if
@@ -740,7 +741,7 @@ allocate-transformation-state s" transformation-state" variable
   dup s" peek" stringcmp 0 = { drop 1 exit } if
   dup s" key" stringcmp 0 = { drop 1 exit } if
 
-  ~ From interpret.e.
+  ~ From language/dynamic/interpret.e.
   dup s" unroll-past-string" stringcmp 0 = { drop 0 exit } if
   dup s" swap-past-string" stringcmp 0 = { drop 0 exit } if
   ~   The following are deliberate omissions: dropstring,
@@ -762,7 +763,7 @@ allocate-transformation-state s" transformation-state" variable
   ~   The following is a deliberate omission: interpret.
   dup s" quit" stringcmp 0 = { drop 0 exit } if
 
-  ~ From linux-dynamic.e.
+  ~ From language/dynamic/linux.e.
   dup s" allocate-timespec" stringcmp 0 = { drop 1 exit } if
   dup s" timespec-seconds" stringcmp 0 = { drop 0 exit } if
   dup s" timespec-nanoseconds" stringcmp 0 = { drop 0 exit } if
@@ -785,7 +786,7 @@ allocate-transformation-state s" transformation-state" variable
   ~   The following is a deliberate omission: handle-crash.
   dup s" install-crash-handler" stringcmp 0 = { drop 0 exit } if
 
-  ~ Created by warm-start in execution.e.
+  ~ Created by warm-start in compilation/execution.e.
   dup s" log" stringcmp 0 = { drop 1 exit } if
   dup s" s0" stringcmp 0 = { drop 1 exit } if
   dup s" r0" stringcmp 0 = { drop 1 exit } if
@@ -821,7 +822,8 @@ allocate-transformation-state s" transformation-state" variable
 ~   This is the alternate version of "create" for use with the label
 ~ transform. Its code is the same as the regular "create" except as noted
 ~ below. It is likely to be extremely useful to read and understand "create"
-~ in dynamic.e before attempting to understand label-create-alternate.
+~ in language/dynamic/dynamic.e before attempting to understand
+~ label-create-alternate.
 : label-create-alternate
   ~   While we could put magic comments here, and be guaranteed to catch every
   ~ word-defining word under the label transform, there's a subtle thing where
@@ -863,8 +865,9 @@ allocate-transformation-state s" transformation-state" variable
 
 ~   This is the alternate version of ":" for use with the label transform. Its
 ~ code is the same as the regular "create" except as noted below. It is likely
-~ to be extremely useful to read and understand ":" in dynamic.e before
-~ attempting to understand label-colon-alternate.
+~ to be extremely useful to read and understand ":" in
+~ language/dynamic/dynamic.e before attempting to understand
+~ label-colon-alternate.
 : label-colon-alternate
   ~ This calls label-create-alternate instead of "create".
   word value@
@@ -888,10 +891,11 @@ allocate-transformation-state s" transformation-state" variable
   ] ;
 
 
-~   So, the way docol's user-facing entry is set up in core.e, it really wants
-~ to reference "here" to create its codeword, but "here" is in the host
-~ address space. We solve this by having it call the word "self-codeword" and
-~ then patching around the address space issue with alternates.
+~   So, the way docol's user-facing entry is set up in language/static/core.e,
+~ it really wants to reference "here" to create its codeword, but "here" is in
+~ the host address space. We solve this by having it call the word
+~ "self-codeword" and then patching around the address space issue with
+~ alternates.
 ~
 ~   If we didn't have this fix, everything would appear to work fine but the
 ~ statically generated user-facing docol from the label transform would have
@@ -906,8 +910,9 @@ allocate-transformation-state s" transformation-state" variable
 
 ~   This is the alternate version of ";" for use with the label transform. Its
 ~ code is the same as the regular "create" except as noted below. It is likely
-~ to be extremely useful to read and understand ";" in dynamic.e before
-~ attempting to understand label-semicolon-alternate.
+~ to be extremely useful to read and understand ";" in
+~ language/dynamic/dynamic.e before attempting to understand
+~ label-semicolon-alternate.
 : label-semicolon-alternate
   ~ This looks up "exit" by label.
   swap-transform-variables
@@ -926,8 +931,9 @@ allocate-transformation-state s" transformation-state" variable
 
 ~   This is the alternate version of ";asm" for use with the label transform.
 ~ Its code is the same as the regular "create" except as noted below. It is
-~ likely to be extremely useful to read and understand ";asm" in dynamic.e
-~ before attempting to understand label-semicolon-assembly-alternate.
+~ likely to be extremely useful to read and understand ";asm" in
+~ language/dynamic/dynamic.e before attempting to understand
+~ label-semicolon-assembly-alternate.
 : label-semicolon-assembly-alternate
   here @ pack-next 8 packalign
   ~ : provide-data
@@ -1232,8 +1238,8 @@ allocate-transformation-state s" transformation-state" variable
 
 
 ~   This implements the label transform for a single word. It is directly
-~ analogous to "interpret", and reading dynamic.e may help in understanding
-~ it, though it's meant to still make sense on its own.
+~ analogous to "interpret", and reading language/dynamic/dynamic.e may help in
+~ understanding it, though it's meant to still make sense on its own.
 ~
 ~ It expects to be called from "label-transform", below, which loops.
 ~
@@ -1772,7 +1778,7 @@ allocate-transformation-state s" transformation-state" variable
 ~
 ~   In practice that means outputting a codeword pointer to run a
 ~ statically-compiled word that does the work. The implementation of
-~ log-load-create is in log-load.e.
+~ log-load-create is in language/static/log-load.e.
 ~
 ~   It's worth keeping in mind that this alternate only gets called for
 ~ manual invocations of "create". It isn't called from the colon alternate.
@@ -1811,8 +1817,9 @@ allocate-transformation-state s" transformation-state" variable
 
 ~   This is the alternate version of ":" for use with the log-load transform.
 ~ Its code is the same as the regular ":" except as noted below. It is likely
-~ to be extremely useful to read and understand ":" in dynamic.e before
-~ attempting to understand "log-load-colon-alternate".
+~ to be extremely useful to read and understand ":" in
+~ language/dynamic/dynamic.e before attempting to understand
+~ "log-load-colon-alternate".
 : log-load-colon-alternate
   word value@
   ~ : blank-line
@@ -1857,10 +1864,11 @@ allocate-transformation-state s" transformation-state" variable
 ~   See notes on label-self-codeword-alternate for what problem this is
 ~ solving.
 ~
-~   Since self-codeword's real definition is in dynamic.e, which absolutely
-~ cannot be loaded yet at the time we output docol at the very beginning of
-~ core.e, we need to provide an alternate for the log-load transform as well,
-~ even though only the label transform has the reproducibility issue.
+~   Since self-codeword's real definition is in language/dynamic/dynamic.e,
+~ which absolutely cannot be loaded yet at the time we output docol at the
+~ very beginning of language/static/core.e, we need to provide an alternate
+~ for the log-load transform as well, even though only the label transform has
+~ the reproducibility issue.
 : log-load-self-codeword-alternate
   ~   It's important to remember, this is not an immediate word! It needs to
   ~ produce correct compiled output, when invoked in compile mode. Since it's
@@ -1885,8 +1893,9 @@ allocate-transformation-state s" transformation-state" variable
 
 ~   This is the alternate version of ";" for use with the log-load transform.
 ~ Its code is the same as the regular ";" except as noted below. It is
-~ likely to be extremely useful to read and understand ";" in dynamic.e
-~ before attempting to understand "log-load-semicolon-alternate".
+~ likely to be extremely useful to read and understand ";" in
+~ language/dynamic/dynamic.e before attempting to understand
+~ "log-load-semicolon-alternate".
 : log-load-semicolon-alternate
   ~   We generate code that looks up "exit" by name and appends it to the
   ~ entry.
@@ -1922,7 +1931,7 @@ allocate-transformation-state s" transformation-state" variable
 ~   This is the alternate version of ";asm" for use with the log-load
 ~ transform. Its code is the same as the regular "create" except as noted
 ~ below. It is likely to be extremely useful to read and understand ";asm" in
-~ dynamic.e before attempting to understand "log-load;asm".
+~ language/dynamic/dynamic.e before attempting to understand "log-load;asm".
 : log-load-semicolon-assembly-alternate
   ~   We generate code that statically invokes log-load-semicolon-assembly,
   ~ which does all the actual work. There's quite a few steps, so it makes
@@ -2300,7 +2309,7 @@ allocate-transformation-state s" transformation-state" variable
 ~ stack at log-load "immediate" time, not at transform time.
 ~
 ~   Anyway, most of the implementation is deferred to pre-packaged words in
-~ log-load.e.
+~ language/static/log-load.e.
 : log-load-left-curly-brace-alternate
   log-load-roll-log-address
 
@@ -2440,8 +2449,8 @@ allocate-transformation-state s" transformation-state" variable
 
 
 ~   This implements the log-load transform for a single word. It is directly
-~ analogous to "interpret", and reading interpret.e may help in understanding
-~ it, though it's meant to still make sense on its own.
+~ analogous to "interpret", and reading language/dynamic/interpret.e may help
+~ in understanding it, though it's meant to still make sense on its own.
 ~
 ~ It expects to be called from "log-load-transform", below, which loops.
 ~
@@ -2640,8 +2649,8 @@ allocate-transformation-state s" transformation-state" variable
 
 
 ~   This implements the log-load transform for all words in a region given as
-~ an input string. It is directly analogous to "quit", in interpret.e, but is
-~ far more complex.
+~ an input string. It is directly analogous to "quit", in
+~ language/dynamic/interpret.e, but is far more complex.
 ~
 ~ (output buffer start, output point, input string pointer
 ~  -- output buffer start, output point)
@@ -2847,8 +2856,9 @@ allocate-transformation-state s" transformation-state" variable
 ~
 ~   Instead, following the principle that different kinds of knowledge on the
 ~ same topic should live close together, we've defined a magic-comment syntax
-~ which allows the assembly-language words in amd64.e to describe their own
-~ metadata, and is versatile enough to do the same for future architectures.
+~ which allows the assembly-language words in language/static/amd64.e to
+~ describe their own metadata, and is versatile enough to do the same for
+~ future architectures.
 ~
 ~   When the compiler operates normally, without the hex transform, these
 ~ magic comments are simply regular comments, and are discarded as the
@@ -2997,10 +3007,10 @@ allocate-transformation-state s" transformation-state" variable
 ~ the length is negative, the span of bytes has its END anchored at the
 ~ address.
 ~
-~   You can see examples of how this syntax is useful in elf.e, where it
-~ describes fields of various header structures. When it fits the situation,
-~ this notation is concise and easy to visually skim both in the actual source
-~ code, and in the generated hex dump.
+~   You can see examples of how this syntax is useful in compilation/elf.e,
+~ where it describes fields of various header structures. When it fits the
+~ situation, this notation is concise and easy to visually skim both in the
+~ actual source code, and in the generated hex dump.
 ~
 ~   Now let's look at some magic comments that do more interesting things.
 ~ The two commands "indent" and "deindent" both create an entry of
@@ -3036,14 +3046,15 @@ allocate-transformation-state s" transformation-state" variable
 ~
 ~   If that doesn't sound confusing, you may not have fully appreciated that
 ~ adjust-line commands don't have to come in the same word as the command that
-~ created the entry they're modifying. For example, in amd64.e, rex-w is a
-~ common helper word called as part of many assembly instructions. It always
-~ outputs a single byte. Commentary in that file describes an accounting
-~ convention whereby keeping track of this byte is rex-w's job, so rex-w also
-~ has a magic comment with an adjust-length command. Whatever word calls rex-w
-~ will have already created a suffix comment giving the name of the
-~ instruction it's implementing, by the time this is called, and rex-w's
-~ call to adjust-length will find that comment's entry and modify it.
+~ created the entry they're modifying. For example, in
+~ language/static/amd64.e, rex-w is a common helper word called as part of
+~ many assembly instructions. It always outputs a single byte. Commentary in
+~ that file describes an accounting convention whereby keeping track of this
+~ byte is rex-w's job, so rex-w also has a magic comment with an adjust-length
+~ command. Whatever word calls rex-w will have already created a suffix
+~ comment giving the name of the instruction it's implementing, by the time
+~ this is called, and rex-w's call to adjust-length will find that comment's
+~ entry and modify it.
 ~
 ~   The use of this may not seem like much for a word like rex-w, which always
 ~ outputs the same number of bytes, but now look at the definition of
@@ -3062,8 +3073,8 @@ allocate-transformation-state s" transformation-state" variable
 ~ is out-of-band compared to the normal Forth value stack. When you're
 ~ implementing an instruction set architecture, you should strongly consider
 ~ defining an accounting convention which makes that clear and unambiguous.
-~ Feel free to consult the convention described at the top of amd64.e for
-~ inspiration.
+~ Feel free to consult the convention described at the top of
+~ language/static/amd64.e for inspiration.
 ~
 ~   All the adjust-* commands change something immediately, as they execute.
 ~ What they adjust differs. In the cases of adjust-length and adjust-start,
@@ -3142,12 +3153,12 @@ allocate-transformation-state s" transformation-state" variable
 ~ out you'll need the full picture in your head.
 ~
 ~   All this time, the hex transform has been executing the compiler, which
-~ is running its guts inside a utility called the label loop (see labels.e).
-~ The compiler guts have been calling their own various internal words and
-~ accumulating their binary output in the label-loop buffer. While this is
-~ happening, the hex transform's various traps have been tracking the latest
-~ output point, executing magic comments, and doing other vital but simpler
-~ tasks.
+~ is running its guts inside a utility called the label loop (see
+~ compilation/labels.e). The compiler guts have been calling their own various
+~ internal words and accumulating their binary output in the label-loop
+~ buffer. While this is happening, the hex transform's various traps have been
+~ tracking the latest output point, executing magic comments, and doing other
+~ vital but simpler tasks.
 ~
 ~   Eventually the label-loop will reach the end of its iteration, and then it
 ~ will either conclude that all the labels in the program have been resolved
@@ -5191,7 +5202,7 @@ allocate-transformation-state s" transformation-state" variable
   ~ add-hex-output-metadata-entry
   newline
   ~   This stack-walking code is modeled off the code in list-callers, in
-  ~ dynamic.e.
+  ~ language/dynamic/dynamic.e.
   ~
 
   ~   This is the bit of the hex transform where all the memory-management
@@ -5267,9 +5278,10 @@ allocate-transformation-state s" transformation-state" variable
 ~ aware that it's also how high-level flow control is implemented.
 ~
 ~   You might find it useful to compare this code to the implementations of
-~ high-level flow-control utilities in log-load.e; it operates under a very
-~ similar set of constraints, except that fortunately we don't have the
-~ nightmare multi-dictionary situation that the log-load transform does.
+~ high-level flow-control utilities in language/static/log-load.e; it operates
+~ under a very similar set of constraints, except that fortunately we don't
+~ have the nightmare multi-dictionary situation that the log-load transform
+~ does.
 : hex-semicolon-alternate
   latest @ entry-to-execution-token 8 +
   dup dup dup
@@ -6188,7 +6200,7 @@ allocate-transformation-state s" transformation-state" variable
 
   ~   We ignore the EOF indication, on the assumption something else will
   ~ detect it and return to the outer loop, the one that's ours. For example,
-  ~ look at "include", in files.e.
+  ~ look at "include", in language/dynamic/files.e.
   drop ;
 
 
@@ -6203,8 +6215,8 @@ allocate-transformation-state s" transformation-state" variable
 
 
 ~   This implements the hex transform for a single word. It is directly
-~ analogous to "interpret", and reading interpret.e may help in understanding
-~ it, though it's meant to still make sense on its own.
+~ analogous to "interpret", and reading language/dynamic/interpret.e may help
+~ in understanding it, though it's meant to still make sense on its own.
 ~
 ~   The hex transform runs code immediately. Whereas most transforms alter
 ~ what the transformed code compiles into, the hex transform alters what it
@@ -6417,8 +6429,8 @@ allocate-transformation-state s" transformation-state" variable
 
 
 ~   This implements the hex transform for all words in a region given as
-~ an input string. It is directly analogous to "quit", in interpret.e, but is
-~ more complex.
+~ an input string. It is directly analogous to "quit", in
+~ language/dynamic/interpret.e, but is more complex.
 ~
 ~ (output metadata buffer start, output buffer start, output point,
 ~  input string pointer -- output buffer start, output point)
diff --git a/evoke.e b/evoke.e
index 7e6225f..1b1453b 100644
--- a/evoke.e
+++ b/evoke.e
@@ -1,34 +1,34 @@
 ~ cat evoke.e | ./evoke > evoke2 && chmod 755 evoke2
 
-s" labels.e" include
-s" elf.e" include
-s" transform.e" include
-s" execution.e" include
+s" compilation/labels.e" include
+s" compilation/elf.e" include
+s" compilation/transform.e" include
+s" compilation/execution.e" include
 
 : read-inputs
   here @ dup
-  s" core.e" pack-file-contents
-  s" linux.e" pack-file-contents
-  s" output.e" pack-file-contents
-  s" amd64.e" pack-file-contents
-  s" execution-support.e" pack-file-contents
-  s" log-load.e" pack-file-contents
+  s" language/static/core.e" pack-file-contents
+  s" language/static/linux.e" pack-file-contents
+  s" language/static/output.e" pack-file-contents
+  s" language/static/amd64.e" pack-file-contents
+  s" language/static/execution-support.e" pack-file-contents
+  s" language/static/log-load.e" pack-file-contents
   0 pack8 8 packalign here !
   s" source-to-precompile" variable
 
   here @ dup
-  s" core.e" pack-file-contents
-  s" linux.e" pack-file-contents
-  s" output.e" pack-file-contents
-  s" amd64.e" pack-file-contents
-  s" execution-support.e" pack-file-contents
-  s" log-load.e" pack-file-contents
-  s" dynamic.e" pack-file-contents
-  s" input.e" pack-file-contents
-  s" interpret.e" pack-file-contents
-  s" flow-control.e" pack-file-contents
-  s" linux-dynamic.e" pack-file-contents
-  s" files.e" pack-file-contents
+  s" language/static/core.e" pack-file-contents
+  s" language/static/linux.e" pack-file-contents
+  s" language/static/output.e" pack-file-contents
+  s" language/static/amd64.e" pack-file-contents
+  s" language/static/execution-support.e" pack-file-contents
+  s" language/static/log-load.e" pack-file-contents
+  s" language/dynamic/dynamic.e" pack-file-contents
+  s" language/dynamic/input.e" pack-file-contents
+  s" language/dynamic/interpret.e" pack-file-contents
+  s" language/dynamic/flow-control.e" pack-file-contents
+  s" language/dynamic/linux.e" pack-file-contents
+  s" language/dynamic/files.e" pack-file-contents
   0 pack8 8 packalign here !
   s" source-to-copy-to-log" variable ;
 read-inputs
diff --git a/hex.e b/hex.e
index 3f9a1d8..cc4e0ce 100644
--- a/hex.e
+++ b/hex.e
@@ -1,8 +1,8 @@
 ~ cat hex.e | ./evoke > hex && chmod 755 hex
 
-s" labels.e" include
-s" elf.e" include
-s" transform.e" include
+s" compilation/labels.e" include
+s" compilation/elf.e" include
+s" compilation/transform.e" include
 
 ~ (buffer start, output point, label offset
 ~  -- buffer start, output point)
diff --git a/inscribe-evoke.e b/inscribe-evoke.e
index 2b459fe..9bb7ddc 100644
--- a/inscribe-evoke.e
+++ b/inscribe-evoke.e
@@ -1,27 +1,27 @@
 ~ cat inscribe-evoke.e | ./evoke > evoke.hex
 
-s" labels.e" include
-s" elf.e" include
-s" transform.e" include
+s" compilation/labels.e" include
+s" compilation/elf.e" include
+s" compilation/transform.e" include
 
 : prepare
   here @ dup
-  s" core.e" pack-file-contents
-  s" linux.e" pack-file-contents
-  s" output.e" pack-file-contents
-  s" amd64.e" pack-file-contents
-  s" execution-support.e" pack-file-contents
-  s" log-load.e" pack-file-contents
-  s" dynamic.e" pack-file-contents
-  s" input.e" pack-file-contents
-  s" interpret.e" pack-file-contents
-  s" flow-control.e" pack-file-contents
-  s" linux-dynamic.e" pack-file-contents
-  s" files.e" pack-file-contents
-  s" labels.e" pack-file-contents
-  s" elf.e" pack-file-contents
-  s" transform.e" pack-file-contents
-  s" execution.e" pack-file-contents
+  s" language/static/core.e" pack-file-contents
+  s" language/static/linux.e" pack-file-contents
+  s" language/static/output.e" pack-file-contents
+  s" language/static/amd64.e" pack-file-contents
+  s" language/static/execution-support.e" pack-file-contents
+  s" language/static/log-load.e" pack-file-contents
+  s" language/dynamic/dynamic.e" pack-file-contents
+  s" language/dynamic/input.e" pack-file-contents
+  s" language/dynamic/interpret.e" pack-file-contents
+  s" language/dynamic/flow-control.e" pack-file-contents
+  s" language/dynamic/linux.e" pack-file-contents
+  s" language/dynamic/files.e" pack-file-contents
+  s" compilation/labels.e" pack-file-contents
+  s" compilation/elf.e" pack-file-contents
+  s" compilation/transform.e" pack-file-contents
+  s" compilation/execution.e" pack-file-contents
   s" evoke.e" pack-file-contents
   0 pack8 8 packalign here !
   s" evoke-source" variable
diff --git a/inscribe-hex.e b/inscribe-hex.e
index e51b9f5..8dd6df8 100644
--- a/inscribe-hex.e
+++ b/inscribe-hex.e
@@ -1,25 +1,25 @@
 ~ cat inscribe-hex.e | ./evoke > hex.hex
 
-s" labels.e" include
-s" elf.e" include
-s" transform.e" include
+s" compilation/labels.e" include
+s" compilation/elf.e" include
+s" compilation/transform.e" include
 
 : prepare
   here @ dup
-  s" core.e" pack-file-contents
-  s" linux.e" pack-file-contents
-  s" output.e" pack-file-contents
-  s" amd64.e" pack-file-contents
-  s" execution-support.e" pack-file-contents
-  s" log-load.e" pack-file-contents
-  s" dynamic.e" pack-file-contents
-  s" input.e" pack-file-contents
-  s" interpret.e" pack-file-contents
-  s" flow-control.e" pack-file-contents
-  s" linux-dynamic.e" pack-file-contents
-  s" files.e" pack-file-contents
-  s" labels.e" pack-file-contents
-  s" elf.e" pack-file-contents
+  s" language/static/core.e" pack-file-contents
+  s" language/static/linux.e" pack-file-contents
+  s" language/static/output.e" pack-file-contents
+  s" language/static/amd64.e" pack-file-contents
+  s" language/static/execution-support.e" pack-file-contents
+  s" language/static/log-load.e" pack-file-contents
+  s" language/dynamic/dynamic.e" pack-file-contents
+  s" language/dynamic/input.e" pack-file-contents
+  s" language/dynamic/interpret.e" pack-file-contents
+  s" language/dynamic/flow-control.e" pack-file-contents
+  s" language/dynamic/linux.e" pack-file-contents
+  s" language/dynamic/files.e" pack-file-contents
+  s" compilation/labels.e" pack-file-contents
+  s" compilation/elf.e" pack-file-contents
   s" hex.e" pack-file-contents
   0 pack8 8 packalign here !
   s" hex-source" variable
diff --git a/dynamic.e b/language/dynamic/dynamic.e
index cf27eb5..270e860 100644
--- a/dynamic.e
+++ b/language/dynamic/dynamic.e
@@ -6,13 +6,13 @@
 ~ Evocation as a language, but which it's not possible to define until global
 ~ variables are available. Therefore it is incompatible with the label
 ~ transform, but compatible with the log-load transform and written to obey
-~ its constraints; see transform.e for more details on that.
+~ its constraints; see compilation/transform.e for more details on that.
 ~
 ~   The code here relies on the words "log", "s0", "r0", "latest", and "here".
 ~ These five global variables are the root of all our other data structures.
-~ They are defined specially by warm-start in execution.e, since there is no
-~ way to create regular definitions for them. Thus, they come to us already
-~ set up.
+~ They are defined specially by warm-start in compilation/execution.e, since
+~ there is no way to create regular definitions for them. Thus, they come to
+~ us already set up.
 ~
 ~   It may not be obvious, but when a regular docol-based Evocation word is
 ~ compiled, it hardcodes pointers to all the words it references, which will
@@ -330,9 +330,9 @@
 : recurse latest @ entry-to-execution-token , ; make-immediate
 
 
-~   The implementation of "find-in" is in core.e, since it's used by the label
-~ and transformation facilities. Once we have full log access, we get the
-~ nicety of using "find" instead.
+~   The implementation of "find-in" is in language/static/core.e, since it's
+~ used by the label and transformation facilities. Once we have full log
+~ access, we get the nicety of using "find" instead.
 ~
 ~ (string pointer -- entry pointer or 0)
 : find latest swap find-in ;
@@ -370,8 +370,9 @@
 ~ all set up to start appending contents to the new word by calling ",".
 ~
 ~   There's a handy diagram of the entry header format under "quick
-~ reference", in the description of the exeuction model in exeuction.e. Create
-~ is responsible for everything up to the codeword, not including it.
+~ reference", in the description of the execution model in
+~ compilation/execution.e. Create is responsible for everything up to the
+~ codeword, not including it.
 ~
 ~   When a word is created in interpret mode using s" to provide a string
 ~ literal, the temporary space that s" uses is in the same place as the
diff --git a/files.e b/language/dynamic/files.e
index 9f353c5..2a8c7c3 100644
--- a/files.e
+++ b/language/dynamic/files.e
@@ -4,8 +4,8 @@
 ~
 ~   This file has high-level features for working with files and the
 ~ filesystem. There's a tension as to what belongs here vs. what belongs in
-~ input.e or output.e, and it's likely there will be some refactoring as the
-~ boundaries become clear.
+~ language/dynamic/input.e or language/static/output.e, and it's likely there
+~ will be some refactoring as the boundaries become clear.
 
 
 ~ (output point, filename -- output point)
diff --git a/flow-control.e b/language/dynamic/flow-control.e
index 25a1931..d4a9dd3 100644
--- a/flow-control.e
+++ b/language/dynamic/flow-control.e
@@ -141,7 +141,7 @@
 ~
 ~   This is much lower-level than the other flow-control stuff, but it isn't
 ~ compatible with the label transform due to relying on r0, so it needs to go
-~ somewhere other than core.e, and this was the closest fit.
+~ somewhere other than language/static/core.e, and this was the closest fit.
 ~
 ~   Anecdotally, this feature is traditionally called "shunt", and sometimes
 ~ "rdrop".
diff --git a/input.e b/language/dynamic/input.e
index 16fa836..9d73c16 100644
--- a/input.e
+++ b/language/dynamic/input.e
@@ -280,8 +280,8 @@ s" main-input-buffer-metadata" find 0x01 swap entry-flags!
 allocate-input-buffer-metadata
 s" main-input-buffer" variable
 
-~   We'll leave it to warm-start, in execution.e, to attach the buffer. It's
-~ easier that way.
+~   We'll leave it to warm-start, in compilation/execution.e, to attach the
+~ buffer. It's easier that way.
 
 : peek main-input-buffer peek-from ;
 : consume main-input-buffer consume-from ;
diff --git a/interpret.e b/language/dynamic/interpret.e
index 7695d0b..0af0dab 100644
--- a/interpret.e
+++ b/language/dynamic/interpret.e
@@ -4,10 +4,11 @@
 ~
 ~   The code in this file defines the basic syntax and semantics of Forth as
 ~ a text-based language. It's written in terms of the underlying executor,
-~ which is implemented and explained in execution.e. The execution model gives
-~ us the concept of "words"; the control and value stacks; and the ability to
-~ call things. It has nothing to say about text, only about the binary form of
-~ the language.
+~ which is implemented and explained in compilation/execution.e and
+~ language/static/execution-support.e. The execution model gives us the
+~ concept of "words"; the control and value stacks; and the ability to call
+~ things. It has nothing to say about text, only about the binary form of the
+~ language.
 ~
 ~   It's traditional in Forth to refer to an act of "compiling" code, which
 ~ in this context means turning it from text into its binary representation.
@@ -36,7 +37,8 @@
 ~   At any rate, the code in this file is responsible for that compilation.
 ~
 ~   It is primarily concerned with managing the contents of an area of memory
-~ we call the "log"; see log-load.e for more detail on terminology.
+~ we call the "log"; see language/static/log-load.e for more detail on
+~ terminology.
 
 ~   As a convenience for "word", we have some facilities for working with
 ~ stack-allocated strings. Yeah, trippy concept. Also, it would be a
@@ -417,7 +419,8 @@ latest @
 
 ~   The counterpart of : is ;.
 : ;
-  ~   See commentary on "literal", in dynamic.e, regarding "lit exit".
+  ~   See commentary on "literal", in language/dynamic/dynamic.e, regarding
+  ~ "lit exit".
   ~
   ~   In regard to the magic comment, this is in the same category as strings
   ~ and high-level flow control, where it's implemented in the base code here
diff --git a/linux-dynamic.e b/language/dynamic/linux.e
index ec9e370..680bdb4 100644
--- a/linux-dynamic.e
+++ b/language/dynamic/linux.e
@@ -3,9 +3,9 @@
 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ~
 ~   Here's some more system calls for the Linux kernel, augmenting the ones in
-~ linux.e. We needed the basic I/O stuff early, to use in building the
-~ interpreter, but there's less-basic stuff that benefits from dynamic
-~ definition. That stuff is here.
+~ language/static/linux.e. We needed the basic I/O stuff early, to use in
+~ building the interpreter, but there's less-basic stuff that benefits from
+~ dynamic definition. That stuff is here.
 ~
 ~   In particular, everything that takes a struct is here, because that lets
 ~ us define the system call next to the allocation stuff, for ease of
@@ -240,11 +240,11 @@
   ~ We also need to set DF = 0, since that's also part of our ABI.
   cld
 
-  ~   Compare this snippet to "execute" in core.e. Instead of taking rax from
-  ~ the stack, we set a hardcoded value picked at the time we generate the
-  ~ wrapper. We then do the same indirect jump via the codeword it points to,
-  ~ which allows the codeword's implementation to take advantage of rax
-  ~ pointing to the callee; that's the property docol cares about.
+  ~   Compare this snippet to "execute" in language/static/core.e. Instead of
+  ~ taking rax from the stack, we set a hardcoded value picked at the time we
+  ~ generate the wrapper. We then do the same indirect jump via the codeword
+  ~ it points to, which allows the codeword's implementation to take advantage
+  ~ of rax pointing to the callee; that's the property docol cares about.
   3roll :rax mov-reg64-imm64
   :rax jmp-abs-indirect-reg64
   ~ (saved location, output point)
diff --git a/amd64.e b/language/static/amd64.e
index 20f140c..925abc0 100644
--- a/amd64.e
+++ b/language/static/amd64.e
@@ -13,9 +13,10 @@
 ~ source behind it. This is similar to how the Forth "!" and "@" words work.
 ~
 ~   These routines use the binary packing routines such as pack64, defined in
-~ core.e. They're called in the same way: an output address which we call the
-~ "output point", followed by data items specific to what's being output. They
-~ also chain together in the same way, returning the updated output point.
+~ language/static/core.e. They're called in the same way: an output address
+~ which we call the "output point", followed by data items specific to what's
+~ being output. They also chain together in the same way, returning the
+~ updated output point.
 ~
 ~   TODO cite the Intel reference manual here and explain the notation used
 ~ for the section citations below
@@ -30,10 +31,10 @@
 ~
 ~   In addition to the actual semantics of the assembly words, there's an
 ~ important layer of meaning atop them. The hex transform, described in detail
-~ in transform.e, modifies a compilation process to produce a commented hex
-~ dump instead of a binary. It includes a magic-comment feature which allows
-~ words that have opinions on what their output's hex dump should look like to
-~ express them.
+~ in compilation/transform.e, modifies a compilation process to produce a
+~ commented hex dump instead of a binary. It includes a magic-comment feature
+~ which allows words that have opinions on what their output's hex dump should
+~ look like to express them.
 ~
 ~   The code in this file makes extensive use of the magic-comment feature.
 ~ Any comment which starts with : as its first word is a magic comment meant
diff --git a/core.e b/language/static/core.e
index 19f851f..10d5d61 100644
--- a/core.e
+++ b/language/static/core.e
@@ -7,7 +7,7 @@
 ~ included statically as part of any generated executable, and a second copy
 ~ of it is later copied into the log when that executable runs. Therefore, it
 ~ is written to obey the constraints of both the label transform, and the
-~ log-load transform; see transform.e for more details on that.
+~ log-load transform; see compilation/transform.e for more details on that.
 
 
 ~ Execution support
@@ -15,11 +15,11 @@
 ~
 ~   There's two words, docol and exit, which are essential parts of the
 ~ indirect-threaded execution model. It would be tempting to put them in
-~ execution.e, so they'd be closer to the explanation of what they do, but
-~ we need two copies of them (just like we do of every other word in this
-~ file), one statically compiled and one in the log. So, they're here, because
-~ that's significantly simpler, even though it creates a little bit of extra
-~ work for the label transform.
+~ compilation/execution.e, so they'd be closer to the explanation of what they
+~ do, but we need two copies of them (just like we do of every other word in
+~ this file), one statically compiled and one in the log. So, they're here,
+~ because that's significantly simpler, even though it creates a little bit of
+~ extra work for the label transform.
 
 
 ~   Docol is the "interpreter" that is responsible for the semantics of words
@@ -125,9 +125,9 @@ here !
 ~ sweet.
 ~
 ~   This code has been written to satisfy the assumptions needed by the label
-~ transform, described in-depth in transform.e. This means that it is, in
-~ effect, written in a restricted dialect of Evocation rather than in the full
-~ language.
+~ transform, described in-depth in compilation/transform.e. This means that it
+~ is, in effect, written in a restricted dialect of Evocation rather than in
+~ the full language.
 ~
 ~   There is definitely plenty of optimization that could be done.
 
@@ -1335,11 +1335,12 @@ here !
 ~ dictionaries, but the main reason for having it is not convenience but
 ~ necessity: During Evocation's startup, there is a period before global
 ~ variables are easily accessible, so there would be no way to implement
-~ "find". The warm-start routine (see execution.e and transform.e) has the
-~ job of fixing that, and it makes extensive use of find-in to do so.
+~ "find". The warm-start routine (see compilation/execution.e and
+~ compilation/transform.e) has the job of fixing that, and it makes extensive
+~ use of find-in to do so.
 ~
-~   The definition of "find" is in dynamic.e, with the other stuff that needs
-~ to access the log.
+~   The definition of "find" is in language/dynamic/dynamic.e, with the other
+~ stuff that needs to access the log.
 ~
 ~ (dictionary pointer, string pointer -- entry pointer or 0)
 : find-in
diff --git a/execution-support.e b/language/static/execution-support.e
index a3d0ca5..1592643 100644
--- a/execution-support.e
+++ b/language/static/execution-support.e
@@ -2,9 +2,9 @@
 ~ ~~~~~~~~~~~~~~~~~
 ~
 ~   These macros are an important part of the execution model described in
-~ execution.e. They're here, in this file, because they need to be statically
-~ available via the label transform, so that the log-load transform can rely
-~ on them.
+~ compilation/execution.e. They're here, in this file, because they need to be
+~ statically available via the label transform, so that the log-load transform
+~ can rely on them.
 
 
 ~ Macro next
diff --git a/linux.e b/language/static/linux.e
index e757ee2..fd15ae0 100644
--- a/linux.e
+++ b/language/static/linux.e
@@ -21,12 +21,13 @@
 ~
 ~   Don't be confused by tools/scripts/syscall.tbl, it's not for x86.
 ~
-~   This file loads early, before dynamic.e. So, although it superficially
-~ appears to be able to do allocation and high-level flow control, those come
-~ from the transforms, which means they're shallow implementations. The stuff
-~ here can't be moved later, because input.e relies on it, and the dynamic
-~ stuff relies on that. So, there's additional Linux functionality in another
-~ file that loads later, linux-dynamic.e.
+~   This file loads early, before anything in language/dynamic/. So, although
+~ it superficially appears to be able to do allocation and high-level flow
+~ control, those come from the transforms, which means they're shallow
+~ implementations. The stuff here can't be moved later, because
+~ language/dynamic/input.e relies on it, and the other dynamic stuff relies on
+~ that. So, there's additional Linux functionality in another file that loads
+~ later, language/dynamic/linux.e.
 
 
 ~ (call number -- return value)
diff --git a/log-load.e b/language/static/log-load.e
index a462c2e..54a9d42 100644
--- a/log-load.e
+++ b/language/static/log-load.e
@@ -13,8 +13,8 @@
 ~ with the log, and more specifically which are useful for helping to bring
 ~ the log into existence. Once the log exists, it can be used to manage
 ~ itself, but there's a bootstrapping challenge in getting there. That
-~ challenge is solved by the warm-start routine in execution.e, which relies
-~ on the words in this file and should load after it.
+~ challenge is solved by the warm-start routine in compilation/execution.e,
+~ which relies on the words in this file and should load after it.
 ~
 ~   Some modern Forths, including Jonesforth, refer to the log as the heap.
 ~ This is a misnomer; a heap is a data structure that allows non-contiguous
@@ -72,8 +72,8 @@
 ~ accurate enough for some purposes, but note that other dictionaries are
 ~ often interleaved with it, their allocations entwining like grape vines even
 ~ while each remains separate, reachable only via its own root. See the
-~ machine label facility, in labels.e, for an example of how a secondary
-~ dictionary can be useful.
+~ machine label facility, in compilation/labels.e, for an example of how a
+~ secondary dictionary can be useful.
 ~
 ~   This may feel tangential, but it's important background and there's no
 ~ better place to explain it: A handle is a pointer to a pointer. The variable
@@ -109,7 +109,7 @@
 
 
 ~   This has the same value as the constant control-stack-size, which is
-~ defined in execution.e. Everything will break if it doesn't.
+~ defined in compilation/execution.e. Everything will break if it doesn't.
 ~
 ~ TODO: remove one of them. Probably the other one.
 : log-offset                        0x10000 ; ~ 64 KiB
@@ -136,8 +136,8 @@
 ~ the global variable "latest". It's inconvenient to keep a log pointer around
 ~ all the time, which is why we stop doing it as soon as possible, but during
 ~ Evocation's startup there's no alternative. This word is used extensively
-~ by code that's been compiled via the log-load transform; see transform.e for
-~ details.
+~ by code that's been compiled via the log-load transform; see
+~ compilation/transform.e for details.
 ~
 ~   It would be possible to unload this word after the log is created, but
 ~ there are rare situations in which it's still useful, such as injecting
@@ -165,9 +165,10 @@
   } if-else ;
 
 
-~   This is the same as "create", from dynamic.e, except that it takes the
-~ log's address as a parameter rather than hardcoding it, so that it can be
-~ used in situations where the normal compilation process isn't yet available.
+~   This is the same as "create", from language/dynamic/dynamic.e, except that
+~ it takes the log's address as a parameter rather than hardcoding it, so that
+~ it can be used in situations where the normal compilation process isn't yet
+~ available.
 ~
 ~   The requisite stack juggling is kind of finicky, sorry if it's hard to
 ~ read, but it's doing the same steps in the same order as the regular
@@ -212,9 +213,10 @@
 
 
 
-~   This is the same as ",", from dynamic.e, except that it takes the log's
-~ address as a parameter rather than hardcoding it, so that it can be used in
-~ situations where the normal compilation process isn't yet available.
+~   This is the same as ",", from language/dynamic/dynamic.e, except that it
+~ takes the log's address as a parameter rather than hardcoding it, so that it
+~ can be used in situations where the normal compilation process isn't yet
+~ available.
 ~
 ~   Again, the stack juggling is kind of a lot, sorry about that.
 ~
@@ -229,13 +231,14 @@
   ! ;
 
 
-~   This is the same as `;asm`, from dynamic.e, except that it takes the
-~ log's address as a parameter rather than hardcoding it, so that it can be
-~ used in situations where the normal compilation process isn't yet available.
+~   This is the same as `;asm`, from language/dynamic/dynamic.e, except that
+~ it takes the log's address as a parameter rather than hardcoding it, so that
+~ it can be used in situations where the normal compilation process isn't yet
+~ available.
 ~
 ~   Its two main responsibilities are to call `pack-next`, from
-~ execution-support.e, and to overwrite the codeword. It also deals with
-~ alignment.
+~ language/static/execution-support.e, and to overwrite the codeword. It also
+~ deals with alignment.
 ~ (log address)
 : log-load-semicolon-assembly
   log-load-here @
@@ -254,9 +257,10 @@
   dup 8 + swap ! ;
 
 
-~   This is the same as "variable", from dynamic.e, except that it takes the
-~ log's address as a parameter rather than hardcoding it, so that it can be
-~ used in situations where the normal compilation process isn't yet available.
+~   This is the same as "variable", from language/dynamic/dynamic.e, except
+~ that it takes the log's address as a parameter rather than hardcoding it, so
+~ that it can be used in situations where the normal compilation process isn't
+~ yet available.
 ~
 ~ (log address, address for new variable word, string pointer -- log address)
 : log-load-variable
@@ -281,8 +285,8 @@
 
 
 ~   A keyword is a word that evaluates to its own address, which makes it
-~ suitable for use as a constant. See more detail on that in dynamic.e,
-~ where "keyword" is defined.
+~ suitable for use as a constant. See more detail on that in
+~ language/dynamic/dynamic.e, where "keyword" is defined.
 ~
 ~   Unlike Common Lisp, the lexer doesn't create keywords for us, we have to
 ~ do it explicitly. If if that were to someday change, the log-load routine
@@ -337,8 +341,9 @@
 
 ~   Now we have a bunch of words that are the back-ends for the log-load
 ~ transform's high-level flow control alternates. These implementations
-~ closely parallel the non-transformed versions in flow-control.e, which
-~ should be referenced in understanding them.
+~ closely parallel the non-transformed versions in
+~ language/dynamic/flow-control.e, which should be referenced in understanding
+~ them.
 ~
 ~   These variants are a bit unusual in their interfaces: They end with the
 ~ log address at the top of the stack, even when they have values to return.
diff --git a/output.e b/language/static/output.e
index 45a29b7..cadd5fb 100644
--- a/output.e
+++ b/language/static/output.e
@@ -2,7 +2,7 @@
 ~ ~~~~~~
 ~
 ~   It is convenient to be able to output text. This depends on the
-~ OS-specific stuff in linux.e, so it's in its own file.
+~ OS-specific stuff in language/static/linux.e, so it's in its own file.
 ~
 ~   The most interesting word we define here is ".", pronounced "dot"; the
 ~ math stuff is needed to implement it.