From fefd6470b974d105224de636843c37f57c664442 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Wed, 9 Sep 2026 21:00:14 -0700 Subject: provide word entries for "here" etc inside the hex transform this replaces the alternates we previously had for those words Change-Id: Ia8c8ca7203e03f511d68a30811fb8a5d262c6312 Force-Push: yes --- transform.e | 57 +++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 35 insertions(+), 22 deletions(-) (limited to 'transform.e') diff --git a/transform.e b/transform.e index a75ea05..3d3ca79 100644 --- a/transform.e +++ b/transform.e @@ -4070,6 +4070,15 @@ allocate-transformation-state s" transformation-state" variable ~ colon's responsibility, so it isn't our responsibility, it'll happen ~ regardless. + ~ Notably, we do NOT share transformation-state. There are at least a + ~ hundred places where it would need to be carefully swapped, and we + ~ already have quite enough of that kind of brittleness in the log-load + ~ transform. Plus, there's no obvious way to do a real push/pop notion for + ~ it, so we wouldn't get arbitrary nesting of transforms anyway. By + ~ letting the code inside the hex transform have its own, separate copy of + ~ transformation-state, we avoid that problem entirely, and it's still not + ~ hard to access the "other" one when circumstances require. + ~ Now we close out colon's responsibilities by switching to compile ~ mode. We return from colon after this. The hex transform will continue ~ by processing the source words that form the regular body of "variable", @@ -4604,20 +4613,6 @@ allocate-transformation-state s" transformation-state" variable ; make-immediate -~ We have to provide alternates for the globals that are bootstrapped by -~ warm-start in normal execution, because code under the hex transform never -~ gets its own copy of warm-start. They don't have to do anything special, -~ though, so we can just use the outer ones. Most of these work unmodified; -~ for "latest" and "here" we invoke the outer copy of the word, but the actual -~ value it sees is the wrapped, inner one, since we swapped that out -~ elsewhere. -: hex-log-alternate log ; -: hex-s0-alternate s0 ; -: hex-r0-alternate r0 ; -: hex-latest-alternate latest ; -: hex-here-alternate here ; - - ~ The code we're compiling may try to exit when it's done. We want to return ~ to our caller instead; we turn that into an nop. This isn't quite correct, ~ but it will work as long as the inner code doesn't try to do anything else @@ -4918,8 +4913,6 @@ allocate-transformation-state s" transformation-state" variable 8 packalign here ! ' hex-tilde-replacement entry-to-execution-token , - ~ We just consumed a newline, so make note of the fact. - 0 has-non-space-this-input-line! } { ~ The third byte was not 0, 0x0a, or 0x20. So our special ~ test failed, but the exit condition isn't met. So we're done @@ -4946,7 +4939,12 @@ allocate-transformation-state s" transformation-state" variable } { ~ For the last time, the exit condition is met. drop - } if-else ; make-immediate + } if-else + + ~ Regardless of what path we exited by, we just consumed a newline, so + ~ make note of the fact. + 0 has-non-space-this-input-line! + ; make-immediate ~ This input helper is a very unusual thing: It's used by hex-transform-one @@ -5033,11 +5031,6 @@ allocate-transformation-state s" transformation-state" variable swap drop ' hex-semicolon-assembly-alternate swap } if dup s" L@'" stringcmp 0 = { swap drop ' hex-L@'-alternate swap } if dup s" L!'" stringcmp 0 = { swap drop ' hex-L!'-alternate swap } if - dup s" log" stringcmp 0 = { swap drop ' hex-log-alternate swap } if - dup s" s0" stringcmp 0 = { swap drop ' hex-s0-alternate swap } if - dup s" r0" stringcmp 0 = { swap drop ' hex-r0-alternate swap } if - dup s" latest" stringcmp 0 = { swap drop ' hex-latest-alternate swap } if - dup s" here" stringcmp 0 = { swap drop ' hex-here-alternate swap } if dup s" bye" stringcmp 0 = { swap drop ' hex-bye-alternate swap } if dup s" allocate" stringcmp 0 = { swap drop ' hex-allocate-alternate swap } if @@ -5219,6 +5212,26 @@ allocate-transformation-state s" transformation-state" variable ~ sure everything else operating on it finds it well-formed. zero-hex-output-metadata + ~ The code under the hex transform never gets a real copy of warm-start, + ~ so it doesn't have the globals "here" and so on. It wants to have the + ~ globals, but it can't, not without our help. Why aren't we helping? + ~ + ~ Oh, right, we're helping right here. We just write them into the inner + ~ log and dictionary directly, by using our outer copy of "variable". These + ~ definitions don't have to do anything special; we point them to the same + ~ addresses as the outer ones. Note though that the actual values the + ~ transformed code sees sees are the wrapped, inner ones, since we swapped + ~ the values out elsewhere. + ~ + ~ If we provided these as alternates instead, that would work for code + ~ that doesn't have a nested transform, but the inner transforms want to be + ~ able to look them up by name. + swap-transform-variables log swap-transform-variables s" log" variable + swap-transform-variables s0 swap-transform-variables s" s0" variable + swap-transform-variables r0 swap-transform-variables s" r0" variable + swap-transform-variables latest swap-transform-variables s" latest" variable + swap-transform-variables here swap-transform-variables s" here" variable + ~ It's important that the stack has nothing of ours on it that persists ~ across iterations, so that client code can add and remove stuff there as ~ it sees fit. -- cgit 1.4.1