In a message dated 7/9/2005 9:24:30 P.M. Central Daylight Time, [EMAIL PROTECTED] writes:
>I am trying to figure out precisely what is destructive overlap. The left hand byte of the destination is inside the source, at least for left-to-right moves. Another point on destructive overlap is that the microcode does not know or care whether any bytes will be changed by such an overlap. E.g., if a field already contains all blanks and you propagate a single byte of X'40' through the field with MVI FIELD,X'40' MVC FIELD+1(some_length_value),FIELD you are doing a destructive overlap, even though no bytes have their contents changed to something different. The bytes, in fact, do have their contents replaced/changed, but with the same value as was there to begin with. The microcode detects the destructive overlap condition before it begins to do the move, and it doesn't know in advance what new contents will replace any given byte. This is the same as doing an Or Immediate of X'00'. This instruction cannot possibly alter any bits to have a different, new value, yet it is detected as an attempt to write into the associated page, so storage protection mechanisms assume write intent and check for your authorization to alter that page regardless of whether your instruction will actually change the contents to a different value. Some instructions allow destructive overlap and others do not (e.g., MVCL). The z/Arch. Princ. of Ops. gives a precise yet succinct definition: "Destructive overlap is said to exist when the result location is used as a source after the result has been stored, assuming processing to be performed one byte at a time." Bill Fairchild ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
