comments: document trap methodology; rename parameters to packalign

"alignment byte count" was confusing since it could mean either the input value that should be used as the modulus base for the desired byte offset, or the number of bytes actually needed to attain modulus zero under that base. in "packalign" itself, this wasn't too confusing, but the hex transform's trap of packalign needs to work with both values alongside each other, so the name needed to be clearer. it is renamed to "alignment byte width".

of course, Evocation doesn't have parameter names as-such, this is just a comment thing

Force-Push: yes
Change-Id: I1c227200ce0b2f6a852c1dc2f2c73f8cdf474f7a

1 files changed, 3 insertions, 3 deletions

diff --git a/core.e b/core.e
index 2aabc6f..bbe1ba8 100644
--- a/core.e
+++ b/core.e
@@ -1209,7 +1209,7 @@ here !
   ~ (output point, source, destination, length)
   memcopy ;
 
-~ (output point, alignment byte count -- output point)
+~ (output point, alignment byte width -- output point)
 : packalign
   { 2dup /% drop { drop exit } unless
     swap 0 pack8 swap } forever ;
@@ -1231,7 +1231,7 @@ here !
 : unpack16 dup 16@ swap 2 + swap ;
 : unpack8 dup 8@ swap 1 + swap ;
 
-~ (proposed size, alignment byte count -- adjusted size)
+~ (proposed size, alignment byte width -- adjusted size)
 : align-size
   dup 3unroll dup 3unroll
   ~ (alignment, alignment, proposed size, alignment)
@@ -1240,7 +1240,7 @@ here !
 ~   You might think this would be identical to packalign, but packalign has
 ~ side effects.
 ~
-~ (input point, alignment byte count -- input point)
+~ (input point, alignment byte width -- input point)
 : unpackalign align-size ;