diff options
Diffstat (limited to 'transform.e')
| -rw-r--r-- | transform.e | 106 |
1 files changed, 54 insertions, 52 deletions
diff --git a/transform.e b/transform.e index 1230883..63ae9c1 100644 --- a/transform.e +++ b/transform.e @@ -241,27 +241,26 @@ { drop zero-input-buffer-metadata } if-else ; -~ TODO rename this to transformation-state -: transform-state-saved-here ; -: transform-state-saved-latest 8 + ; -: transform-state-output-buffer-start 2 8 * + ; -: transform-state-user-stack-depth 3 8 * + ; -: allocate-transform-state +: transformation-state-saved-here ; +: transformation-state-saved-latest 8 + ; +: transformation-state-output-buffer-start 2 8 * + ; +: transformation-state-user-stack-depth 3 8 * + ; +: allocate-transformation-state 4 8 * allocate - dup transform-state-saved-here 0 swap ! - dup transform-state-saved-latest 0 swap ! - dup transform-state-output-buffer-start 0 swap ! - dup transform-state-user-stack-depth 0 swap ! ; -allocate-transform-state s" transform-state" variable + dup transformation-state-saved-here 0 swap ! + dup transformation-state-saved-latest 0 swap ! + dup transformation-state-output-buffer-start 0 swap ! + dup transformation-state-user-stack-depth 0 swap ! ; +allocate-transformation-state s" transformation-state" variable ~ When calling the label facility during a transformation, it's necessary ~ to use the real, non-wrapped "here" and "latest". : swap-transform-variables - here @ transform-state transform-state-saved-here @ - here ! transform-state transform-state-saved-here ! - latest @ transform-state transform-state-saved-latest @ - latest ! transform-state transform-state-saved-latest ! ; + here @ transformation-state transformation-state-saved-here @ + here ! transformation-state transformation-state-saved-here ! + latest @ transformation-state transformation-state-saved-latest @ + latest ! transformation-state transformation-state-saved-latest ! ; ~ We deal with a few address spaces. There's the "host" address space, the ~ space this process performing the compilation is using for itself. There's @@ -295,12 +294,12 @@ allocate-transform-state s" transform-state" variable ~ (output offset -- host address) : offset-to-host-address-space ~ Don't transform null pointers - dup { transform-state transform-state-output-buffer-start @ + } if ; + dup { transformation-state transformation-state-output-buffer-start @ + } if ; ~ (host address --output offset) : host-address-space-to-offset ~ Don't transform null pointers - dup { transform-state transform-state-output-buffer-start @ - } if ; + dup { transformation-state transformation-state-output-buffer-start @ - } if ; ~ (host address inside the output buffer -- target address) : host-address-space-to-target @@ -314,12 +313,15 @@ allocate-transform-state s" transform-state" variable : describe-transformation ." active here " here @ .hex64 space ." latest " latest @ .hex64 newline - ." saved here " transform-state transform-state-saved-here + ." saved here " transformation-state transformation-state-saved-here @ .hex64 space - ." latest " transform-state transform-state-saved-latest @ .hex64 newline - ." output start " transform-state transform-state-output-buffer-start + ." latest " transformation-state transformation-state-saved-latest @ .hex64 newline - ." user stack depth " transform-state transform-state-user-stack-depth + ." output start " + transformation-state transformation-state-output-buffer-start + @ .hex64 newline + ." user stack depth " + transformation-state transformation-state-user-stack-depth @ .hex64 newline ; @@ -330,7 +332,7 @@ allocate-transform-state s" transform-state" variable ~ use, or not, as they prefer, called user stack depth tracking. The log-load ~ transform uses it; the label transform does not. The most difficult part of ~ the tracking is the heler word below; it also relies on the user-stack-depth -~ field of the transform-state variable. +~ field of the transformation-state variable. ~ ~ What does user stack depth mean? Well, for every transform there's some ~ notion of running a word "immediately"; for the log-load transform, it means @@ -811,7 +813,7 @@ allocate-transform-state s" transform-state" variable dup s" L@'" stringcmp 0 = { drop 1 exit } if dup s" L!'" stringcmp 0 = { drop -1 exit } if dup s" labels" stringcmp 0 = { drop 1 exit } if - dup s" allocate-transform-state" stringcmp 0 = { drop 1 exit } if + dup s" allocate-transformation-state" stringcmp 0 = { drop 1 exit } if ~ If we get here, that's a problem. Emit an error message to make sure ~ it's easy to diagnose. We also return a comically large negative value, @@ -822,8 +824,8 @@ allocate-transform-state s" transform-state" variable ~ (delta --) : transform-apply-stack-delta - transform-state transform-state-user-stack-depth @ + - transform-state transform-state-user-stack-depth ! ; + transformation-state transformation-state-user-stack-depth @ + + transformation-state transformation-state-user-stack-depth ! ; ~ Label transform implementation @@ -1241,7 +1243,7 @@ allocate-transform-state s" transform-state" variable ~ If not, we look up the word in the regular, non-transformed dictionary ~ and use that for immediate mode. over { dup - transform-state transform-state-saved-latest @ swap find-in + transformation-state transformation-state-saved-latest @ swap find-in 3roll drop swap } unless ~ (name as stack string, immediate entry pointer, name pointer) @@ -1404,9 +1406,9 @@ allocate-transform-state s" transform-state" variable ~ since client code will make its own updates to them and then rely on those ~ updates having taken effect. So we do the swap just once, here outside the ~ loop, and set it back when the loop ends. - here @ transform-state transform-state-saved-here ! - latest @ transform-state transform-state-saved-latest ! - over transform-state transform-state-output-buffer-start ! + here @ transformation-state transformation-state-saved-here ! + latest @ transformation-state transformation-state-saved-latest ! + over transformation-state transformation-state-output-buffer-start ! here ! 0 latest ! ~ Now the stack has nothing of ours on it, so client code can do its thing. @@ -1421,15 +1423,15 @@ allocate-transform-state s" transform-state" variable ~ back. The internal "here" is also the output point, and will become our ~ return value. The internal "latest" is discarded. { here @ - transform-state transform-state-saved-here @ here ! - transform-state transform-state-saved-latest @ latest ! + transformation-state transformation-state-saved-here @ here ! + transformation-state transformation-state-saved-latest @ latest ! ~ (output point) - ~ Though we don't actually use transform-state outside of this + ~ Though we don't actually use transformation-state outside of this ~ invocation, for tidiness we zero it out. - 0 transform-state transform-state-saved-here ! - 0 transform-state transform-state-saved-latest ! - 0 transform-state transform-state-output-buffer-start ! + 0 transformation-state transformation-state-saved-here ! + 0 transformation-state transformation-state-saved-latest ! + 0 transformation-state transformation-state-output-buffer-start ! ~ Also put the input source back how it was. main-input-buffer pop-input-buffer @@ -1515,7 +1517,7 @@ allocate-transform-state s" transform-state" variable ~ to put the log address on top, as preparation for calling something that ~ relies on it. : log-load-roll-log-address - transform-state transform-state-user-stack-depth @ + transformation-state transformation-state-user-stack-depth @ ~ The amount we're rolling includes the log address, which is not a user ~ value, so we add 1. 1 + @@ -1526,7 +1528,7 @@ allocate-transform-state s" transform-state" variable ~ to put the log address back at the bottom, as cleanup after calling ~ something that relies on it. : log-load-unroll-log-address - transform-state transform-state-user-stack-depth @ + transformation-state transformation-state-user-stack-depth @ ~ The amount we're rolling includes the log address, which is not a user ~ value, so we add 1. 1 + @@ -1537,7 +1539,7 @@ allocate-transform-state s" transform-state" variable ~ to put the saved label value on top, as preparation for calling something ~ that consumes it. : log-load-roll-saved-label - transform-state transform-state-user-stack-depth @ + transformation-state transformation-state-user-stack-depth @ ~ The amount we're rolling includes both the log address and the label ~ value, neither of which are user values, so we add 2. 2 + @@ -1548,7 +1550,7 @@ allocate-transform-state s" transform-state" variable ~ to put a saved label value on the bottom, as a way of safely storing it away ~ when it's newly generated. : log-load-unroll-saved-label - transform-state transform-state-user-stack-depth @ + transformation-state transformation-state-user-stack-depth @ ~ The amount we're rolling includes both the log address and the label ~ value, neither of which are user values, so we add 2. 2 + @@ -2142,7 +2144,7 @@ allocate-transform-state s" transform-state" variable ~ the transformed code is expected to have on the stack, based on its ~ hardcoded understanding of each word that's expected to be relevant, looked ~ up by the word's name. The number of items is stored in the user-stack-depth -~ field of transform-state. +~ field of transformation-state. ~ ~ There is no adjustment done on the saved value, since it's created in the ~ target address space and then also used in the target address space. It @@ -2512,11 +2514,11 @@ allocate-transform-state s" transform-state" variable ~ loop, and set it back when the loop ends. ~ ~ We also take this opportunity to initialize the output-buffer-start and - ~ user-stack-depth fields of transform-state. - here @ transform-state transform-state-saved-here ! - latest @ transform-state transform-state-saved-latest ! - over transform-state transform-state-output-buffer-start ! - 0 transform-state transform-state-user-stack-depth ! + ~ user-stack-depth fields of transformation-state. + here @ transformation-state transformation-state-saved-here ! + latest @ transformation-state transformation-state-saved-latest ! + over transformation-state transformation-state-output-buffer-start ! + 0 transformation-state transformation-state-user-stack-depth ! here ! 0 latest ! ~ Now the stack has nothing of ours on it, so client code can do its thing. @@ -2531,16 +2533,16 @@ allocate-transform-state s" transform-state" variable ~ back. The internal "here" is also the output point, and will become our ~ return value. The internal "latest" is discarded. { here @ - transform-state transform-state-saved-here @ here ! - transform-state transform-state-saved-latest @ latest ! + transformation-state transformation-state-saved-here @ here ! + transformation-state transformation-state-saved-latest @ latest ! ~ (output point) - ~ Though we don't actually use transform-state outside of this + ~ Though we don't actually use transformation-state outside of this ~ invocation, for tidiness we zero it out. - 0 transform-state transform-state-saved-here ! - 0 transform-state transform-state-saved-latest ! - 0 transform-state transform-state-output-buffer-start ! - 0 transform-state transform-state-user-stack-depth ! + 0 transformation-state transformation-state-saved-here ! + 0 transformation-state transformation-state-saved-latest ! + 0 transformation-state transformation-state-output-buffer-start ! + 0 transformation-state transformation-state-user-stack-depth ! ~ Also put the input source back how it was. main-input-buffer pop-input-buffer |