Re: Redefining a DS

On 11/04/2010, at 9:03 PM, Dennis Lovelady wrote:

First off: it was a point of interest more than anything else. In very
simple terms, my understanding is that EVAL is roughly equivalent to MOVEL
in the same sense that EVALR is roughly equivalent to MOVE.

Essentially that's true, although neither form of EVAL implement the more obscure behaviour of MOVE operations nor does EVAL tolerate numeric overflow by default.

This is the
basis behind my question. It also turns out to lead to invalid assumptions,
but just to justify where I was coming from... in a world where eval is
strictly a left-to-right operation, and where LEN = 1:
eval %Subst(mystring: LEN) = mystring ;
would seem to imply (since it's left-to-right) that byte 1 of mystring would
be moved to byte 2 of mystring; and then byte 2 of mystring would be moved
to byte3, et cetera, propagating the leftmost value throughout the length of
string. Values of LEN that are equal to some arbitrary "array element
length" would have the same effect: Elem2 = Elem1, then Elem3 = Elem2 and so
on.

That would be true if you discount (or disallow) the compiler generating a temporary variable behind the scenes. Given that the compiler can detect coincident operands I expect it will copy mystring into a temporary and then copy from the temporary to mystring at the new starting position. But equally, I suppose it might copy from the right as you suggest,

These are both things we did as common practice for efficiently clearing
and/or initializing areas of memory in Assembler.

But in Assembly Language the Assembler only does what you tell it to do. If you didn't make use of a temporary then you changed the value you are about to copy thus each element (byte) gets the same value. With HLLs a reasonable compiler (i.e., not C and its ilk) will generally do what is reasonably expected by the programmer.

It turns out (or appears)
that the MI is pulling some tricks under the covers.

Probably not the MI but rather the compiler.

I was really curious about this, so I tried the same thing, using MEMCPY, as
follows:
MemCpy %Addr(mystring)+1: %Addr(mystring): %Len(mystring)-1) ;
I expected this to be functionally equivalent to my old, trusty-dusty:
MVC OUTPUT,OUTPUT-1
Which is strictly a left-to-right operation. To my amazement, it didn't do
what I thought it would do... it had to switch to a Right-to-Left operation
in order to pull off what it did do, which was start with 01234567 and end
with 00123456.

To finally kill this thing off, I tried the opposite:
Memcpy %Addr(myString): %Addr(myString) + 1: %Len(myString)-1) ;
This translated to a Left-to-Right operation, since my result was 12345677.
(sigh.)

Umm, memcpy() output is undefined when copying objects that overlap. Not surprising you get unexpected behaviour. If you want predictable behaviour for coincident operands you need to use memmove().

Usually I distrust a machine that tries to do what I want rather than what I
say. This is my first distrust of this particular family. So I wonder if
there's a way to do that old thing at all on AS/400, other than in a loop
where it's done by hand? I didn't try other languages, but given that
memcpy worked that way, I doubt it.

%SUBARR appears to give the behaviour you expect where:

%subarr(myNumbers: 2 ) = %subarr(mynumbers : 1 );

will fill the array with the value of the first element. However, this behaviour seems to be a side-effect and cannot be relied upon (see my previous e-mail for supporting documentation).


Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------