|
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
As an Amazon Associate we earn from qualifying purchases.
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.