move to a struct-based definition of compilation inputs

the migration process was a pain - order of operations for the rebuild was rough to figure out - but the actual implementation is way easier than all that stack juggling

Force-Push: yes
Change-Id: I8bbe4dfb39e5f0ed69f9759e87ac6ab79ec7558b

1 files changed, 83 insertions, 63 deletions

diff --git a/compilation/top-level.e b/compilation/top-level.e
index 669c074..7c714cb 100644
--- a/compilation/top-level.e
+++ b/compilation/top-level.e
@@ -15,6 +15,16 @@
 ~ different levels of abstraction.
 
 
+: compilation-definition-top-level-filename ;
+: compilation-definition-static-filenames 8 + ;
+: compilation-definition-dynamic-filenames 2 8 * + ;
+: compilation-definition-boot-filenames 3 8 * + ;
+: compilation-definition-compile-header 4 8 * + ;
+: compilation-definition-compile-footer 5 8 * + ;
+: allocate-compilation-definition
+  6 8 * allocate ;
+
+
 ~   This accepts a pointer to an existing buffer for file contents to be
 ~ appended to, and another pointer to the start of a packed list of filenames.
 ~ The filename list consists of null-terminated strings, all directly abutting
@@ -114,15 +124,18 @@
   ;
 
 
-~   Given a description of an executable, compile and output that executable
-~ as runnable binary, to standard output.
+~   Given a compilation-definition structure which is a description of an
+~ executable, compile and output that executable as runnable binary, to
+~ standard output.
 ~
-~ (static source filename list, dynamic source filename list,
-~  boot source filename list, compile-header word name,
-~  compile-footer word name --)
-: enchant-from-description
-  5 roll 5 roll 5 roll read-inputs
-  ~ (compile-header word name, compile-footer word name, source to precompile,
+~ (definition structure pointer --)
+: enchant-from-definition
+  dup dup dup
+  compilation-definition-boot-filenames @ 3unroll
+  compilation-definition-dynamic-filenames @ 3unroll
+  compilation-definition-static-filenames @ 3unroll
+  read-inputs
+  ~ (definition structure pointer, source to precompile,
   ~  source to copy to log, source to copy textually)
 
   ~   We need an execution token to pass to label-loop. There's no reason to
@@ -130,8 +143,8 @@
   ~ executable word body directly.
   here @
   docol ,
-  6 roll find entry-to-execution-token literal
-  5 roll find entry-to-execution-token literal
+  4 pick compilation-definition-compile-header @ literal
+  4 pick compilation-definition-compile-footer @ literal
   4 roll literal
   3 roll literal
   swap literal
@@ -143,20 +156,22 @@
   bye ;
 
 
-~   Given a filename containing the top-level source of an executable, compile
-~ and output that executable as runnable binary, to standard output.
+~   Look up the word "latest-executable-data" dynamically, thus taking the
+~ most recent copy of it at runtime, invoke it, and use the resulting value
+~ as the compilation definition for enchant-from-definition.
 ~
-~ (top-level source filename --)
+~   The typical way to use this word is immediately after including the
+~ top-level source file of the executable you want to enchant.
 : enchant
-  include drop
   s" latest-executable-data" find entry-to-execution-token execute
-  enchant-from-description ;
+  enchant-from-definition ;
 
 
-~   Given a filename containing the top-level source of an executable, compile
-~ and output that executable as a commented hex dump, to standard output.
-~ Processing the hex dump through "hex" will give an identical binary to what
-~ "enchant" would have produced, with the same inputs.
+~   Given a compilation-definition structure which is a description of an
+~ executable, compile and output that executable as commented hex dump, to
+~ standard output. Processing that hex dump through "hex" will give an
+~ identical binary to what "enchant" would have produced, with the same
+~ inputs.
 ~
 ~   Please notice that if the thing we're compiling is "evoke" and its list
 ~ of source files has changed, we'll be working with the new list, not
@@ -166,15 +181,8 @@
 ~ being compiled; see the description of "enchant", above, for more details
 ~ and discussion of the implications.
 ~
-~ (top-level source filename --)
-: inscribe
-  allocate-string-if-temporary
-  dup include drop
-  s" latest-executable-data" find entry-to-execution-token execute
-  ~ (top-level source filename, static source filename list,
-  ~  dynamic source filename list, boot source filename list,
-  ~  compile-header word name, compile-footer word name --)
-
+~ (definition structure pointer --)
+: inscribe-from-definition
   ~   We begin by constructing the full text of all the source that will be
   ~ run inside the scope of the hex transform. That necessarily includes not
   ~ only the compilation machinery, but the transformation system. Notably
@@ -182,52 +190,53 @@
   ~ "enchant", and having a stray unused copy of inscribe is harmless, so we
   ~ don't try to exclude it.
   here @ dup
-  ~ (top-level source filename, static source filename list,
-  ~  dynamic source filename list, boot source filename list,
-  ~  compile-header word name, compile-footer word name,
-  ~  hex-transformed source pointer, output point)
+  ~ (definition structure pointer, hex-transformed source pointer,
+  ~  output point)
 
-  6 pick read-inputs-from-filename-list
-  5 pick read-inputs-from-filename-list
-  4 pick read-inputs-from-filename-list
-  8 roll pack-file-contents
+  2 pick compilation-definition-static-filenames @
+  read-inputs-from-filename-list
+
+  2 pick compilation-definition-dynamic-filenames @
+  read-inputs-from-filename-list
+
+  2 pick compilation-definition-boot-filenames @
+  read-inputs-from-filename-list
+
+  ~   The top-level source file will try to look up its own filename, but this
+  ~ is all on standard input, so it doesn't have one. We must deceive it!
+  s"  : current-input-file-name [ s" pack-raw-string
+  ~ Outputting quotation marks is, as always, a pain.
+  0x22 pack8 s"  " pack-raw-string
+  2 pick compilation-definition-top-level-filename @ pack-raw-string
+  0x22 pack8
+  s"  literal-string ] ; " pack-raw-string
+
+  ~ Having set that up, now we can include the actual top-level file.
+  2 pick compilation-definition-top-level-filename @
+  pack-file-contents
 
   ~   We need to create a call to "enchant" in the code under transformation.
   ~ That call doesn't need to be arrived at in exactly the same way as an
   ~ independent call would be, since it doesn't become part of the output, it
   ~ only needs to have the same effect.
   ~
-  ~   So, we can take the filename list pointers that will become parameters
-  ~ to "enchant" and pass them in directly, heedless of the fact they
-  ~ reference locations in the outer log.
-  s"  0x" pack-raw-string 7 roll pack-hex64
-  s"  0x" pack-raw-string 6 roll pack-hex64
-  s"  0x" pack-raw-string 5 roll pack-hex64
-  ~ (compile-header word name, compile-footer word name,
-  ~  hex-transformed source pointer, output point)
-
-  ~   We do not have that luxury with the two compile hooks; we need copies of
-  ~ them that are under the hex transform. We produce code that looks them up
-  ~ by name. Notice that this is possible because we included the top-level
-  ~ source in our full source text.
+  ~   With that said, though, since one way or another it's going to be
+  ~ looking up latest-executable-data dynamically, there's no reason to try
+  ~ any sophisticated means of passing individual fields or anything.
   ~
-  ~   Outputting quotation marks is, as always, a pain.
-  s"  s" pack-raw-string 0x22 pack8 s"  " pack-raw-string
-  4 roll pack-raw-string
-  0x22 pack8
-  s"  allocate-string" pack-raw-string
-
-  s"  s" pack-raw-string 0x22 pack8 s"  " pack-raw-string
-  3roll pack-raw-string
-  0x22 pack8
-  s"  allocate-string" pack-raw-string
-  ~ (hex-transformed source pointer, output point)
-
-  s"  enchant-from-description" pack-raw-string
-  ~ (hex-transformed source pointer, output point)
+  ~   It might seem as if that's an unnecessary level of indirection, but for
+  ~ the two compile hooks we specifically need to make sure the enchantment
+  ~ uses the copies of them that are under the hex transform. So, one way or
+  ~ another it's always relying on the code from the top-level source file.
+  s"  enchant" pack-raw-string
+  ~ (definition struction pointer, hex-transformed source pointer,
+  ~  output point)
   0 pack8 8 packalign here !
 
+  ~ That's everything we need from the definition.
+  swap drop
   ~ (hex-transformed source pointer)
+
   1024 1024 4 * * allocate
   1024 1024 8 * * allocate
   ~ (hex-transformed source pointer, binary buffer pointer,
@@ -235,3 +244,14 @@
 
   swap dup 4 roll hex-transform bye ;
 
+
+~   Look up the word "latest-executable-data" dynamically, thus taking the
+~ most recent copy of it at runtime, invoke it, and use the resulting value
+~ as the compilation definition for enchant-from-definition.
+~
+~   The typical way to use this word is immediately after including the
+~ top-level source file of the executable you want to inscribe.
+: inscribe
+  s" latest-executable-data" find entry-to-execution-token execute
+  inscribe-from-definition ;
+