× 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.


  • Subject: RE: Z-ADD or Eval?
  • From: "jt" <jt@xxxxxx>
  • Date: Tue, 22 Aug 2000 19:05:29 -0400
  • Importance: Normal

Jim

I was always told that, on the S/38, MOVE and Z-ADD created the exact same
MI instruction.  I verified this is still true today by looking at the IRP
from an RPG compile by specifying GENOPT(*LIST).  Both use the same MI
instruction 'copy numeric value 0.0 to field X':

CPYNV X,P'0.0'

It is unlikely that ILE RPG would be any different, but since you cannot get
the IRP list for ILE programs, it's hard to say for sure.

(BTW, I also use *ZEROS, just for readability.)

jt

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Jim Langston
Sent: Tuesday, August 22, 2000 5:15 PM
To: RPG400-L@midrange.com
Subject: Re: Z-ADD or Eval?


Z-Add being faster than Move all has to do with the assembly language
instruction.  Z-Add actually maps to a specific assembly langauge
instruction,
which was called ZADD, I believe, in the 80x86 series of chips, probably the
same in the IBM chip (Motorolla?)

I don't know what happened to the Z-Add instruction on the new RISC chips,
or even if it's faster anymore. But we are talking like 2 or 3 chip cycles
anyway.

The reason I'm not using %Found and such is because I'm on V3R7M0 and
it doesn't seem to have them.

Okay, I'll go with the Eval.

Incedently, who do you use 0 instead of *Zero?  *Zero is just easier for me
to read.

Regards,

Jim Langston

Scott Klement wrote:

> Ummm...  why would Z-Add be more efficient than MOVE? That seems odd to
> me.  Math is slower than just moving bytes around...
>
> Your code doesn't look modern to me because it uses an indicator :)
> You should find a way to do this that doesn't involve an indicator.
>
> If you're only doing a single line of code (as in your examples) I find
> conditioning indicators to be just as good as if statements.  But, if
> you're going to do more than one line of code conditioned on that same
> indicator, the "if" technique is better.
>
> This is how I code things like that, when I _must_ use indicators:
>
> c   99              eval       EqSize = 0
>
> or:
>
> c                   if         *in99
> c                   eval       EqSize = 0
> c                   endif
>
> I doubt I'll ever use Z-ADD again.  :)
>

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

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.