× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Jon Paris wrote:
> 
> After all move doesn't fill the target field, it overlays (with conversion
> if needed) a part of it.  Eval on the other hand always changes the entire
> target field and always begins at the first position of the source and
> target.  Since no calculations are involved with Eval the compiler probably
> doesn't bother to check for overlaps since it has no impact.
> 
> Move is also a "legacy" op-code.  Moving overlapping fields back in the days
> of the S/3, 34 and 36 would (if memory serves) have a different effect to
> that on 400s and iSeries.  It may be because of that that move is defined as
> not permitting overlaps and hence the compiler error.
> 

Actually, EVAL could have problems with overlapping fields too, but it
handles them if there's a possibility the fields might overlap.  Fields
can overlap explicitly by being overlapping subfields of a data
structure, and they can also overlap physically through reference
parameters or based variables.  (We see cases of parameters overlapping
all the time when too-short parameters are passed from the command
line.)

I don't know the history of the no-overlap rule, but it applies to most
(all?) of the fixed-form opcodes, Z-ADD, CAT etc.

I don't know for sure why EVAL was left out of the rule, but I think it
was indeed because it completely fills whatever is specified on the left
hand side (which might not be a complete field in the case of
left-hand-side %SUBST).  It's possible that filling the whole field
would put garbage into any of the other operands of the EVAL operation,
but any operation might put garbage into other storage that overlaps the
target of the operation, so the only thing that is important is that the
pre-operation value of the other operands is used, and not whatever
value they might have during or after the operation.

Although what I just said about always using the pre-operation value of
the other operands is entirely true - somewhere in the manuals it says
that if you pass a parameter by reference to a procedure as part of an
expression, and the parameter gets updated, and you also use the
parameters as another operand of the eval operation, it's undefined
whether the initial value or the updated value of the parameter would be
used.

For example 
  y = 3;
  x = y + modifyParm(y) + y;
This probably wouldn't use 3 for all the "y" operands if the procedure
changes its parameter.

The same thing could happen if you called a procedure and it modified a
global variable.
  y = 3;
  x = y + modifyY() + y;
This probably wouldn't use 3 for all the "y" operands if the procedure
changes global variable Y.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.