diff options
| -rw-r--r-- | log-load.e | 22 | ||||
| -rw-r--r-- | transform.e | 121 |
2 files changed, 88 insertions, 55 deletions
diff --git a/log-load.e b/log-load.e index 8053291..1339d7b 100644 --- a/log-load.e +++ b/log-load.e @@ -189,8 +189,9 @@ ~ 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. ~ -~ TODO: rework things so there's a common backend, rather than two -~ implementations +~ 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 +~ "create". ~ ~ (log address, string pointer -- log address) : log-load-create @@ -218,3 +219,20 @@ ~ (log address, output point) over log-load-here swap drop ! ; + +~ This is the same as ",", from interpret.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. +~ +~ (log address, value -- log address) +: log-load-comma + swap log-load-here swap 3unroll + ~ (log address, value, here) + @ swap pack64 + ~ (log address, updated here value) + 3roll log-load-here swap 3unroll + ~ (log address, updated here value, here) + ! ; + diff --git a/transform.e b/transform.e index 42901f4..35ccc9b 100644 --- a/transform.e +++ b/transform.e @@ -27,7 +27,8 @@ ~ work that must be done when the runtime starts up, but the benefit is that ~ it can reference data that doesn't exist at compile-time. Most crucially, ~ it can reference the "here" and "latest" pointers in the log, which are -~ required for all the usual word-definition stuff to work. +~ required for all the usual word-definition stuff to work, and whose +~ addresses are not known until runtime. ~ ~ The log-load transform may also be useful for experimental tasks such as ~ creating additional, independent logs, or injecting Evocation into another @@ -596,45 +597,34 @@ allocate-transform-state s" transform-state" variable ~ This is the alternate version of "create" 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 "create" -~ in interpret.e before attempting to understand log-load-create. -: log-load-create - ~ dup stringlen 1 + dup 3unroll - ~ here @ 10 + 3unroll memmove - ~ here @ - - ~ ~ This value of "latest" is going into the generated output, so we need - ~ ~ to map it to the target address space. It's stored in the host address - ~ ~ space to make immediate words work as expected, so the appropriate - ~ ~ conversion is host-address-space-to-target. - ~ latest @ host-address-space-to-target pack64 - ~ 0 pack8 - ~ 0 pack8 - ~ + - ~ 8 packalign - ~ here @ latest ! - - ~ ~ Now we're immediately after the word header, which is where the codeword - ~ ~ will be. This is the value the label should taken on, so we set it. - ~ dup host-address-space-to-offset - ~ here @ 10 + - 0 swap ~ DO NOT SUBMIT +~ transform. This one is quite unlike the regular "create"; rather than +~ creating an entry on the log directly, its job is to output words which, +~ when they're later executed, will do create's job. +~ +~ The implementations of log-load-find-execution-token and log-load-create +~ are in log-load.e. +~ +~ (string pointer --) +: log-load-create-alternate swap-transform-variables - intern-label set-label + ~ Looking these up in reverse order saves us some stack juggling. Does it + ~ help readability, or hurt it? Who can say... + L@' log-load-create + L@' litstring swap-transform-variables - - ~ here ! + offset-to-target-address-space , ~ litstring + swap here @ swap packstring 8 packalign here ! + offset-to-target-address-space , ~ log-load-create ; ~ This is the alternate version of ":" 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 ":" in interpret.e -~ before attempting to understand "log-load:". -: log-load: +~ Its code is the same as the regular ":" except as noted below. It is likely +~ to be extremely useful to read and understand ":" in interpret.e before +~ attempting to understand "log-load-colon-alternate". +: log-load-colon-alternate ~ ~ This calls "log-load-create" instead of "create". - word value@ log-load-create dropstring + word value@ log-load-create-alternate dropstring ~ This looks up "docol" by label. ~ swap-transform-variables @@ -649,10 +639,10 @@ allocate-transform-state s" transform-state" variable ~ This is the alternate version of ";" for use with the log-load transform. -~ Its code is the same as the regular "create" except as noted below. It is +~ Its code is the same as the regular ";" except as noted below. It is ~ likely to be extremely useful to read and understand ";" in interpret.e -~ before attempting to understand "log-load;". -: log-load; +~ before attempting to understand "log-load-semicolon-alternate". +: log-load-semicolon-alternate ~ ~ This looks up "exit" by label. ~ swap-transform-variables ~ L@' exit @@ -671,7 +661,7 @@ allocate-transform-state s" transform-state" variable ~ 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 ~ interpret.e before attempting to understand "log-load;asm". -: log-load;asm +: log-load-semicolon-assembly-alternate ~ here @ pack-next 8 packalign here ! ~ latest @ dup unhide-entry entry-to-execution-token ~ ~ The codeword needs to be transformed to the target address space. @@ -708,10 +698,14 @@ allocate-transform-state s" transform-state" variable ~ the alternate if so. 0 swap ~ (name as stack string, placeholder, name pointer) - dup s" create" stringcmp 0 = { swap drop ' log-load-create swap } if - dup s" :" stringcmp 0 = { swap drop ' log-load: swap } if - dup s" ;" stringcmp 0 = { swap drop ' log-load; swap } if - dup s" ;asm" stringcmp 0 = { swap drop ' log-load;asm swap } if + dup s" create" stringcmp 0 = { + swap drop ' log-load-create-alternate swap } if + dup s" :" stringcmp 0 = { + swap drop ' log-load-colon-alternate swap } if + dup s" ;" stringcmp 0 = { + swap drop ' log-load-semicolon-alternate swap } if + dup s" ;asm" stringcmp 0 = { + swap drop ' log-load-semicolon-assembly-alternate swap } if drop ~ (name as stack string, 0 or alternate entry pointer) @@ -742,18 +736,28 @@ allocate-transform-state s" transform-state" variable ~ It's a number. dropstring-with-result - drop ~ TODO placeholder - interpreter-flags @ 0x01 & { ~ We're in compile mode, so we want to generate code which will compile ~ the number. - ~ TODO + + swap-transform-variables + ~ Just like in log-load-create-alternate, we do these in reverse. + L@' log-load-comma + L@' log-load-comma + L@' litstring + swap-transform-variables + + offset-to-target-address-space , ~ litstring + here @ s" lit" packstring 8 packalign here ! + offset-to-target-address-space , ~ log-load-comma + swap , ~ the value + offset-to-target-address-space , ~ log-load-comma + 0 exit } if ~ We're in interpret mode, so we want to generate code which will push the ~ number to the stack. - ~ TODO swap-transform-variables L@' lit swap-transform-variables offset-to-target-address-space , , 0 exit @@ -764,31 +768,42 @@ allocate-transform-state s" transform-state" variable ~ runtime. We of course have no way to check what flags it will have, which ~ means immediate words don't work with this transform. We still treat it ~ differently based on whether we're in compile mode. - ~ interpreter-flags @ 0x01 & { - ~ ~ We're in compile mode. We compile code that compiles the word. - ~ ~ TODO - ~ dropstring 0 exit - ~ } if + interpreter-flags @ 0x01 & { + ~ We're in compile mode. We compile code that compiles the word. + value@ + swap-transform-variables + ~ Just like in log-load-create-alternate, we do these in reverse. + L@' log-load-comma + L@' log-load-find-execution-token + L@' litstring + swap-transform-variables + + offset-to-target-address-space , ~ litstring + 3roll here @ swap packstring 8 packalign here ! + offset-to-target-address-space , ~ log-load-find-execution-token + offset-to-target-address-space , ~ log-load-comma + dropstring 0 exit + } if ~ (name as stack string) ~ We're in immediate mode. We compile code that runs the word immediately. ~ We check whether there's a label for the word; if there is, we output ~ that. Otherwise we output code that looks it up and runs it. ~ TODO + value@ swap-transform-variables - ~ Looking these up in reverse order saves us some stack juggling. Does - ~ help readability, or hurt it? Who can say... + ~ This is reverse order again. L@' execute L@' log-load-find-execution-token L@' litstring swap-transform-variables + offset-to-target-address-space , ~ litstring 3roll here @ swap packstring 8 packalign here ! offset-to-target-address-space , ~ log-load-find-execution-token offset-to-target-address-space , ~ execute - ~ There's no such thing as not finding the word, with this transform. So ~ we just exit. dropstring 0 ; |