There seems to be a common misconception that MVC can't move 256 bytes.
It certainly can. It cannot move zero bytes, but that's not much of a
limitation.
On 2/12/2012 17:45, Bernd Oppolzer wrote:
There was a little misunderstanding on my part;
I thought that robin suggested the decrement by one should be done
using a macro, which made no sense to me.
Of course, a macro which does the whole VARCHAR move makes much
more sense.
But still: as John Gilmore pointed out, such a macro should offer
many options, to be useful in the special situations.
For example, are the lengths of the operands known at compile time or
not,
how to handle differing lengths (fill with blanks etc.,
or leave the rest untouched). In some special situations,
such a commonly usable macro will probably generate some unnecessary
instructions, compared to hand coded machine instructions.
You will probably have to pay for the convenience.
On the other hand: the pattern
LTR Rx,Rx
IF (P)
BCTR Rx,0
EX Rx,MVCCMD
EIF
which I would normally use to handle the situation
(if the VARCHAR is known to be of length less than 256)
does not seem enough complicated or error-prone to me,
that the use of a macro would be justified.
My error (BALR instead of BCTR) is an exception - that kind of error
happened to me only once in 30 years of ASSEMBLER experience, and I hope
it will never happen again. After the module containing this error was
fixed in 1997, it ran without modification until 2010, when it was
serviced
again due to a change request by the customer.
Kind regards
Bernd
Am 12.02.2012 17:01, schrieb John Gilmore:
Again, context is all. Bernd's point,
Man muss übrigens nicht mit Kanonen auf Spatzen schießen.
is well taken (Bowdlerized, it is overkill to launch a torpedo at a
canoe, even if you sink it.)
Still, I do have a MOVECHRS macro that optimizes, generates MVC, MVC
loops, MVCLE, etc., as appropriate. In some situations I use it; in
others I code an MVC; it all depends.
For the situation under discussion, that of a (halfword current-length
prefixed) PL/I VARYING CHARACTER value, a test for a nul string, one
of length zero, is clearly required, as it would be for a
nul-delimited C string. Moreover, that test needs to be in close
proximity to the top of the loop. The decision where exactly to put
it would require examination of all of the code involved. In some
cases any competent person would take the same decision; in others
not.
On 2/13/12, robin<[email protected]> wrote:
From: Gerhard Postpischil<[email protected]>
Date: Sunday, 12 February 2012 13:45
On 2/12/2012 5:44 PM, robin wrote:
In this case, BCTR is inappropriate, because the length can be zero,
and use of SH provides the means to test for negative and to skip
the MVC (or CLC).
You're drawing an unwarranted conclusion. It is quite possible
that the length was tested earlier on in the code, and the
author knows better than you that the BCTR is safe.
The programming world is littered with "it can't happen" cases.
Everyone knows Murphy's Law ("If anything can go wrong, it will").
But not many have heard of Robert's Law? ("Even if it can't go
wrong, it
will".)
So, even it the length were tested prior, one can't assume that all
will be well when the EX is reached.
The MVC can be destructive, and the only case where it isn't is when
the destination is of length 256.
The intended use of BCTR suggests to me that the author has not
allowed for
the
length being zero.
What it also suggests to me that the code is not bulletproof.
Setting up for a variable-length move (or compare) using EX
involves decrementing a length. That is part and parcel of the move
(compare), and is best kept as a unit in order to avoid bugs.
For such a routine operation as a variable move, a macro
would offer many advantages.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
John Gilmore, Ashland, MA 01721 - USA
