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



Also, for those who don't use or care about MI, the built-in such as
CPYBYTES, MEMCPY and MEMCMP don't care about the 64k limit of RPG's own
built-in functions and opcodes. So if you are writing a library of utilities
(such as the RPG xTools www.rpgxtools.com) using these MI built-ins or other
operations like them can help you write more generic handlers that not only
support RPG IV's capabilities today, they also, with little or no changes,
support any enhancements to the language. For example, when they went from
32k field lengths to 64k, no code in the RPG xTools had to be changed. Why?
Because cpybytes() supports up to 16 megabytes (at least). In fact, the
CPYUSRSPC (copy user space data) xTool uses __memcpy to copy the entire user
space in one pass, even if that user space is several megabytes in length.
-Bob Cozzi


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Bob Cozzi
Sent: Thursday, September 16, 2004 1:01 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Builtins

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.



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

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.