diff options
| -rw-r--r-- | transform.e | 62 |
1 files changed, 62 insertions, 0 deletions
diff --git a/transform.e b/transform.e index 474ba13..7d392f1 100644 --- a/transform.e +++ b/transform.e @@ -155,6 +155,45 @@ ~ ~ The log-load transformation and its alternates rely on the following ~ labels, all of which must be defined elsewhere: TODO +~ +~ +~ About the hex transform +~ ~~~~~~~~~~~~~~~~~~~~~~~ +~ +~ The hex transform's role is a bit different. Whereas the label and +~ log-load transforms are used as part of generating an executable binary, the +~ hex transform produces a commented hex dump that, when later processed by +~ the "hex" tool, produces that same binary. It achieves this by modifying +~ various words which are core parts of Evocation to keep track of appropriate +~ comments and other metadata, and modifying the output facility to output a +~ hex dump with any attached comments, rather than raw bytes. +~ +~ By its nature, the hex transform needs to be able to cope with other +~ transforms running inside itself; that is, the transformation facility needs +~ to be reentrant. The other transforms don't have to cope with that, since +~ the code they run is mostly just about creating word definitions, but the +~ code given to the hex transform will normally include a call to label-loop, +~ all the memory manipulation that happens as part of binary generation, and +~ various output words. +~ +~ While the label and log-load transforms allow Evocation to be a +~ self-hosting compiler, the hex transform attains the even higher bar of +~ making Evocation a "self-bootstrapping" compiler, able to create a running +~ copy of itself without having any sort of pre-existing compiler at all, only +~ a hex converter or similar small tool. The idea is that the hex converter is +~ small and simple enough that it's easy to perform a BINARY audit on, and +~ that there need be no other binary artifacts in the chain of trust. +~ +~ This is not a new concept, but as far as Irenes are aware this name for it +~ is a new coinage. The approach of using a hex-to-binary conversion tool as +~ the initial bootstrapping stage is due to MesCC, which is quite inspiring in +~ that regard. +~ +~ The key insight is that, some sense, the difference between source code +~ and binary is the ability to have comments. +~ +~ The hex transform DOES NOT WORK yet. It's still in development. +~ TODO update this note when it does work ~ Buffer- and address-management helpers @@ -2785,11 +2824,21 @@ allocate-transformation-state s" transformation-state" variable ~ apply for immediate execution; compilation will use the inner label system ~ instead. : hex-L@'-alternate + s" L@'" find dup { + entry-to-execution-token execute + exit + } { drop } if-else + word dropstring transformation-state transformation-state-label-scratch @ ; make-immediate : hex-L!'-alternate + s" L!'" find dup { + entry-to-execution-token execute + exit + } { drop } if-else + word dropstring transformation-state transformation-state-label-scratch ! ; make-immediate @@ -2824,6 +2873,19 @@ allocate-transformation-state s" transformation-state" variable ~ nor an entry in the inner dictionary is found, the outer dictionary is ~ checked; otherwise it's irrelevant. ~ +~ The point of this precedence rule is that string literals, which require +~ special treatment, will be using the inner implementation by the time it +~ gets to actually generating an executable image. It's important that there +~ not be any alternates altering the generated code, only the program actually +~ being compiled. Other literal syntaxes, such as tick, don't have alternates +~ at all (the hex transform manages to be more parsimonious with alternates +~ than other transforms), and will always be using inner versions. +~ +~ The precedence rule does fail to have the desired effect for label +~ references. For these, the alternates take the unusual step of manually +~ calling the inner versions when they exist. +~ TODO think through whether the precedence rule is actually doing anything... +~ ~ It expects to be called from "hex-transform", below, which loops. ~ ~ (-- done) |