If the check is to eliminate 16 duplicate bytes that follow, shouldn't the CLC
be checking for a length of 16 (17 less 1)?
The Op started with this instruction...seems to be a byte short for what is
being described.
00251A D50E 5001 5000 00001 00000 8688 CLC 1(15,R5),0(R5)
Cliff McNeill
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On
Behalf Of Rob van der Heij
Sent: Tuesday, October 05, 2010 8:46 AM
To: [email protected]
Subject: Re: 16-bytes the same
On Tue, Oct 5, 2010 at 3:29 PM, Bill Fairchild <[email protected]> wrote:
> I couldn't think of a "useful" reason for such code either, other than
> perhaps as a teaching exercise. But I was going to reply "Who cares what the
> value of it is? Why not just answer the original question? A long time ago
> someone wondered "What's the use of this strange thing that always points in
> the same direction if we put it on top of a piece of wood so it will float on
> water? It's no good. Let's throw it overboard."
I too appreciate the opportunity to learn. It would also be
interesting to hear about possible performance implications...
Such ideas often make me think (and ask) about where to apply the new
knowledge, or maybe just to learn more.
In this case I realized that the exact comparison might be affected by
code page. So you would compare one byte with the original, and the
others with each other. That made sense to me since we don't have
another easy way to compare a string with a character (or do we)?
> Then Frank Ramaekers' reply reminded me that I, too, have written code to
> replace 16 (or hundreds, or thousands, of) consecutive identical bytes with
> the one phrase "Same as above." And I have done so more than once.
But that would involve comparing two strings, rather than a string
with a character? I would be pretty annoyed reading a dump and get
portions omitted with "... these 32 byte are all the same, guess what
they are..."
| Rob
