ByteBlt:
PROCEDURE [to, from: Environment.Block, overLap: OverLapOption ← ripple]
RETURNS [nBytes:
CARDINAL] ~
INLINE {
IF overLap # ripple THEN ERROR
ELSE nBytes ← PrincOpsUtils.ByteBlt[to: LOOPHOLE[to], from: LOOPHOLE[from]]
};
Moves as much as it can, and tells you how much that was. 0 length in either to or
from is ok, it will just return 0. If you startIndex>stopIndexPlusOne in either to
or from, it will complain since that doesn't make sense. "overLap" indicates the
means for moving the bytes. It only has a noticable effect if to and from define
overlapping fields. If overLap = ripple, a low address to high address move takes
place with no attempt to deal with the overlapping (i.e., after the move (to+i)^ may
not be the same as (from+i)^ was before the move). overLap = ripple is useful for
initializing a block of storage to some value. If overlap = move, then ByteBlt
preserves the contents of from (i.e., (to+i)^ after the move will be the same as
(from+i)^ was before the move). It does a BLT for the easy cases and BitBlt whenever
possible for other cases. In some instances, overLap = move may result in a Mesa
DO...ENDLOOP construct being used to do the ripple.