On Tue, 19 Aug 2025 at 15:57, Rupert Reynolds <
[email protected]> wrote:
> Back in the 1990s I was using an inline
>
> EX_ME MVC DEST(*-*),SOURCE
> EX R0,EX_ME
> because our per4mans guys said branching around the MVC cost more than
> moving the 1st byte twice, while storing the MVC elsewhere might slow data
> cacheing.
I've seen this many times in many different code bases. But I also saw
code, written by a very smart guy, that had it like this:
EX R0, EX_ME
EX_ME MVC 0(*-*,R14),0(R9)
where R9 and R14 were the source and dest pointers, obviously.
Well, it's really the same, right? If you're going to MVC the first byte
twice for the reasons explained above (justified or not) surely the order
doesn't matter...?
The code worked fine for about 20 years, and then a change to a field size
elsewhere provoked it into subtle failure. What the code was doing was
shifting a field left to make room for another field to its right. Going
left doesn't make for a destructive overlap within the MVC (as where you
want to propagate a byte to the right does), but it did mean that after the
"real" (executed) MVC, the second (dummy) one copied that single byte from
a place that had already been changed by the first MVC.
I got in touch with the (retired) author and told him about his 20-year-old
bug. I also searched our code base for the same construct, and it occurred
only in that single module, but several times. He not surprisingly had no
memory for why he chose to do it that way there.
Well this is off-topic for the larger question, but is perhaps an argument
other than performance to not use the double MVC construct.
Tony H.
