From a /34/36 perspective this is true. Both were limited to 64K as a
program size (really, 64K); a program could be larger but the compiler tried
to overlay parts of the program that could be paged in and out. I once had
to fix a program that would not compile simply because it was too big even
with overlays. Back then there was a manual (forget the name) that
specified how many bytes each op-code took and, where relevant, under what
conditions. I think that a MOVE required fewer bytes than a Z-ADD, but I do
remember for sure is that with either one '0' required more bytes than
*Zeros. Specifically, when the factors were the same length, the minimum
code was used. This "rule" applied to op-codes ADD and SUB, too.
On another note, we were trying to explain to a new programmer what Z-ADD0
actually did. After going through the manual explanation (which apparently
still puzzled him), my boss explained that it was like doing a MOVE of all
zeros to the result field. The light bulb finally got lit and from then on
we were told to use MOVE, rather than Z-ADD, when resetting numeric fields,
and Blank After in the output specs was verboten; reset the fields in Calcs
where they could be easily seen.
Jerry C. Adams
IBM i Programmer/Analyst
I really didn't say everything I said. - Yogi Berra
--
A&K Wholesale
Murfreesboro, TN
615-867-5070
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Brian Parkins
Sent: Thursday, March 24, 2011 5:51 AM
To: RPG programming on the IBM i / System i
Subject: Re: Question about legacy coding style
<Another question about "why" (not "what is it doing").
<Why use a MOVE opcode when initializing a numeric field as opposed to the
<more clearly numeric-only Z-ADD opcode?
<The question is motivated towards understanding what the historical bias
<was, in terms of choosing MOVE instead of Z-ADD.
At the time it may have been thought faster to MOVE, (map bytes right to
left) than a Z-ADD, (set variable to zero then add zero). Performance was
more of a consideration in the S/34 days.
Brian Parkins.
midrange.com
