From ab7caa91be01fe092fdeca65dc797f60abba6406 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Sun, 30 Aug 2026 21:30:42 -0700 Subject: significant reduction of raw access to the metadata structure Force-Push: yes Change-Id: Ibdf713ba0e66c7a3b4632dacdfa7f10733112b0a --- transform.e | 121 ++++++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 76 insertions(+), 45 deletions(-) (limited to 'transform.e') diff --git a/transform.e b/transform.e index 35a720c..bae74e2 100644 --- a/transform.e +++ b/transform.e @@ -2616,7 +2616,7 @@ allocate-transformation-state s" transformation-state" variable ~ ... + 0x00 - ... + 0x07 Data pointer ~ ... + 0x08 - ... + 0x0f Referenced data length ~ ... + 0x10 - ... + 0x17 String pointer -~ (entry fields repeat at successive offsets) +~ (entry fields repeat at successive offsets, until...) ~ ... + 0x00 - ... + 0x07 (end) Zero, used as a delimiter : hex-output-metadata-label-loop-buffer-start ; : hex-output-metadata-label-loop-buffer-length 8 + ; @@ -2626,6 +2626,18 @@ allocate-transformation-state s" transformation-state" variable : hex-output-metadata-entry-string 2 8 * + ; : hex-output-metadata-next-entry 3 8 * + ; +~ Initialize the contents of the output metadata to all zeroes. This is +~ called from hex-transform at its top level, at the very start, to make sure +~ everything is structurally valid. We can't store real values at that point, +~ because they don't exist yet. The actual label-loop buffer, per its name, +~ won't be allocated until label-loop is called, so we can't possibly know its +~ address till then. +: zero-hex-output-metadata + transformation-state transformation-state-output-metadata @ + dup hex-output-metadata-label-loop-buffer-start 0 swap ! + dup hex-output-metadata-label-loop-buffer-length 0 swap ! + dup hex-output-metadata-first-entry 0 swap ! ; + ~ (pointer -- boolean) : is-in-label-loop-buffer dup @@ -2638,58 +2650,77 @@ allocate-transformation-state s" transformation-state" variable swap hex-output-metadata-label-loop-buffer-length @ + > && ; +~ (data start, data length, string pointer, entry pointer --) +: hex-output-metadata-entry! + dup hex-output-metadata-entry-string 3roll swap ! + dup hex-output-metadata-entry-data-length 3roll swap ! + dup hex-output-metadata-entry-data-start 3roll swap ! + drop ; + +~ (entry pointer, data start, data length, string pointer +~ -- next entry pointer) +: pack-hex-output-metadata-entry + 3 pick hex-output-metadata-entry! + hex-output-metadata-next-entry ; + ~ (data start, data length, string pointer --) : add-hex-output-metadata-entry - transformation-state transformation-state-output-metadata @ - hex-output-metadata-first-entry - { dup @ dup { dup 2 pick >= drop } if } { - hex-output-metadata-next-entry - } while - 4 roll pack64 3roll pack64 swap pack64 0 pack64 - drop ; + 2 pick is-in-label-loop-buffer { + transformation-state transformation-state-output-metadata @ + hex-output-metadata-first-entry + { dup @ dup { dup 2 pick >= drop } if } { + hex-output-metadata-next-entry + } while -: add-hex-output-metadata-top-of-file-entries + 4 unroll pack-hex-output-metadata-entry + 0 pack64 drop + } { drop drop drop } if-else ; + +~ This is the followup to zero-hex-output-metadata, above. Once we do have +~ the label-loop buffer, we need to create some default entries. This is +~ called in the first label-loop iteration by hex-allocate-replacement, and +~ it's called before subsequent iterations by the hook on reset-labels defined +~ in hex-colon-alternate. +~ +~ This overwrites whatever entries currently exist with the new ones, and +~ adds a zero delimiter at the end. +~ +~ It requires the header to have already been initialized; in particular it +~ requires the label-loop buffer start pointer to be valid. +: create-hex-output-metadata-top-of-file-entries transformation-state transformation-state-output-metadata @ dup hex-output-metadata-label-loop-buffer-start @ swap hex-output-metadata-first-entry ~ (label buffer start, metadata output point) - over pack64 ~ Entry data start - 0 pack64 ~ Entry data length + over 0 s" This file is a commented hexadecimal representation of a compiled " - pack64 ~ Entry string + pack-hex-output-metadata-entry - over pack64 ~ Entry data start - 0 pack64 ~ Entry data length + over 0 s" program, the output of Evocation's hex transform. The comments are " - pack64 ~ Entry string + pack-hex-output-metadata-entry - over pack64 ~ Entry data start - 0 pack64 ~ Entry data length + over 0 s" intended to allow a human reader to audit it. You can convert it to a " - pack64 ~ Entry string + pack-hex-output-metadata-entry - over pack64 ~ Entry data start - 0 pack64 ~ Entry data length + over 0 s" runnable executable by piping it through the program named 'hex' and " - pack64 ~ Entry string + pack-hex-output-metadata-entry - over pack64 ~ Entry data start - 0 pack64 ~ Entry data length + over 0 s" chmodding the output 755. The difference between a source and a binary " - pack64 ~ Entry string + pack-hex-output-metadata-entry - over pack64 ~ Entry data start - 0 pack64 ~ Entry data length + over 0 s" is comments! Enjoy. :)" - pack64 ~ Entry string + pack-hex-output-metadata-entry - over pack64 ~ Entry data start - 0 pack64 ~ Entry data length - s" " pack64 ~ Entry string + over 0 s" " pack-hex-output-metadata-entry - 0 pack64 ~ End-of-entries delimiter - drop drop ; + 0 swap ! ~ End-of-entries delimiter + drop ; : hex-tilde-alternate [ ' ~ entry-to-execution-token , ] ; make-immediate @@ -2946,7 +2977,8 @@ allocate-transformation-state s" transformation-state" variable ~ of label-loop. We need to reinitialize all the metadata entries whenever ~ that happens, and reset-labels is a good semantic match for that ~ behavior, so it's a good place for the hook. - ' add-hex-output-metadata-top-of-file-entries entry-to-execution-token , + ' create-hex-output-metadata-top-of-file-entries + entry-to-execution-token , ~ Fall through to the inner implementation. ' ] entry-to-execution-token execute @@ -3070,13 +3102,15 @@ allocate-transformation-state s" transformation-state" variable ~ (result pointer, size) transformation-state transformation-state-output-metadata @ - ~ (result pointer, size, metadata pointer) - 2 pick pack64 ~ Label buffer start - swap pack64 ~ Label buffer length - drop + hex-output-metadata-label-loop-buffer-length ! ~ (result pointer) - add-hex-output-metadata-top-of-file-entries ; + dup + transformation-state transformation-state-output-metadata @ + hex-output-metadata-label-loop-buffer-start ! + ~ (result pointer) + + create-hex-output-metadata-top-of-file-entries ; ~ ... then, we define the alternate. ~ @@ -3354,13 +3388,10 @@ allocate-transformation-state s" transformation-state" variable transformation-state transformation-state-output-metadata ! ~ Now the stack has nothing of ours on it, so client code can do its thing. - ~ Initialize the contents of the output metadata. See the notes above - ~ hex-output-metadata-* for details on its format. - transformation-state transformation-state-output-metadata @ - 0 pack64 ~ Label buffer start - 0 pack64 ~ Label buffer length - 0 pack64 ~ End-of-entries delimiter - drop + ~ We don't have the real values yet, so we can't create the initial + ~ entries in the output metadata, but we can and should zero it out to make + ~ sure everything else operating on it finds it well-formed. + zero-hex-output-metadata ~ 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 -- cgit 1.4.1