Re: Redefining a DS

There is a memcpy that is a C/C++ function. It's been one of the runtime functions of C for the longest time. And people write versions that perform better than, say, whatever is the standard version.

This is distinct from the MI one - at least at V5R1 that is not obviously surfaced - QSYSINC/MIH does not contain an include for it. That only means that it is not surfaced for use in HLLs. Maybe!

So if you use memcpy, you are using the C function. If you are able to use _memcpy, that will be a thin layer over the MI function.

I had included in my post the prototype from the link you cite, I think. Not sure which came first, the C runtime or the MI function.

I don't know what the compiler does - have a feeling that its actions are its own, the only thing you can do is call it with the right parameters. The include in QSYSINC for MI stuff does have some branches based on various defines, not too sure that those will have any bearing from RPG - suspect not. And especially when these are not explicitly exposed for HLL use.

I'm rambling - time to go to rehearsal and to something where I know better what I'm talking about!!

Oh - there IS a MEMMOVE MI instruction, as well - the one that is supposed to be safe with overlapping source and destination. (Well, at least the C-runtime discussion of the same-named function says that!)

Vern

Dennis Lovelady wrote:

I thought memcpy is a C function - there is no implicit connection to
anything on the i. How it's implemented depends on whatever version of
C/C++ you use. If it has been a direct mapping to some MI function -
well, we can't depend on that, cuz implementation changes as better
ways
are found. And I'd be very surprised to be able to depend on this

Ummm... it is my understanding (perhaps flawed? Barbara? Simon? Bueller?)
that "procedures" like _memcpy are actually interfaces to the MI
instruction.

I would suggest that the MI memcpy operation code (and yes, there is one -
see
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/tstudio/tech_ref/mi/MEMCPY
.htm) similarity to the C function is an engineered "coincidence."

I would also suggest that since IBM have opted to provide such interfaces
into the lower levels of the system, they won't take those interfaces away.
Finally, I see occasional suggestion from Barbara and others to use the MI
built-ins (see http://archive.midrange.com/rpg400-l//200301/msg00433.html as
an example), so I say that with some confidence.

As Simon tried to point out, the MEMCPY.htm link I provided above warns
about overlapping fields and undefined results, so I won't be trying the MI
after all.

But I still would like to know why Simon said that about it being more
likely the compiler than the MI. Is _memcpy() an interface to MI, and does
the ILE RPG compiler influence its actions?

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"I'm one of those mayors whose management style is to allow free and
unlimited debate up to a point."
-- Washington, D.C. mayor Marion Barry