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



Right,
      ** Faster mem-to-mem copy without embedded pointers:
     D cpybytes        PR                  ExtProc('_CPYBYTES')
     D  pTarget                        *   Value
     D  pSource                        *   Value
     D  nLength                      10U 0 Value 
-Bob Cozzi

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Keith Carpenter
Sent: Thursday, September 16, 2004 12:15 PM
To: rpg400-l
Subject: Re: Builtins

The next question will probably be
What's the actual built-in name for CPYBYTES() ?

You can probably guess that it's _CPYBYTES


Unless someone knows a better way, I use the following to determine the
builtin names.

Gene Gaunt posted a REXX procedure which produces a listing of built-ins
names.  The REXX procedure is here.
http://archive.midrange.com/mi400/200006/msg00111.html

Not all built-ins listed are available for general use, so you must check
the infocenter as to whether the built-in is documented for usage.  Some of
the undocumented ones are "privileged" instructions that are "blocked" from
normal usage.  But this is a topic that can be further discussed over on the
MI400 list.


Here's a list of the first few entries from a V4R5 system.

__memcpy                   97     0     0    15     0
__memcmp                   97     0     0    17     0
__memset                   97     0     0    10     0
_MEMMOVE                   97     0     0    16     0
__strlen                   97     0     0    23     0
__strcpy                   97     0     0    11     0
__strcmp                   97     0     0    18     0
__abs                      44
__fabs                     44
_STRNCMPNULL               97     0     0    19     0
_STRNCPYNULL               97     0     0    13     0
_STRNCPYNULLPAD            97     0     0    12     0
_CPYBYTES                  97     0     0     9     0
_CPYBWP                    97     0     0    14     0
_FINDBYTE                  97     0     0    20     0
_MEMCHR                    97     0     0    22     0
_STRCHRNULL                97     0     0    21     0
_CMPTOPAD                  97     0     0   429     0
_TSTBTS                    97     0     0     1     0



Of interest is the built-in name and built-in number (the forth column
number across).  Looking at _CPYBYTES, the number is 9.  This is the same
built-in number as found in the infocenter documentation.

Apparently that the importance of the built-in number relates to how the
compiler (binder) ultimately resolves the function for generating the
executible code.


Keith



> IBM occasionally moves certain instructions (from HLL's) into MI built-ins
> to improve performance. Obviously memcpy() is called a lot in C and to
> improve performance, they made it an MI instruction too.
> There is also CPYBYTES() which is twice as fast at copying bytes of data
> from one location to another as memcpy or cpybla, but the cost of that is
> that you can't have any embedded pointers in the data being copied.
> -Bob

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.