David said:
Keith Thompson said:
David T. Ashley said:
And no, that's not as arbitrary a restriction as it might
appear. Consider: memcpy() copies its data as if by copying
the individual bytes, one by one.
Not always. On machines with alignment restrictions (or equivalently,
better instructions available if best alignment is guaranteed), memcpy
can
take a few different forms. The most common one is:
if (both pointers are aligned)
Do best instruction copy as many times as possible;
Finish any remainder using less-efficient byte copies;
else
Use less-efficient byte copy;
[...]
Yes, but that's still *as if* by copying the individual bytes.
(Though volatile qualification might affect this; I see the word
"volatile" in the subject, but I can't see the previous article.)
Most of the posts show a lack of experience with actual hardware. In
practical applications using a buffer, usually the buffer is controlled by
other control register locations -- A-B is a typical arrangement where the
asynchronous process and the one being compiled have some other way to
coordinate which process is doing what to which memory locations at which
time (many modern communication peripherals are designed in this way). A
true situation where memcpy() can't be safely used for moving buffered data
is relatively rare.
Yes, but that's still *as if* by copying the individual bytes.
Alignment and choice of machine instructions are relevant when dealing with
"memory" locations interfaced in unusual ways. In some interface
arrangements, using the wrong instructions will "double-bounce" the location
and have unintended effects. Using "*as if*" to apply to locations declared
volatile is nonsense. That contradicts the notion of "volatile". There is
no "*as if*" with "volatile".
The last thing I need is individuals without enough experience with
practical devices opining on whether the post I made adds value.
David, I chose my language with some care: I wrote "as if
by copying the individual bytes," and that is precisely what I
meant. You responded that this was "not always" the case, and
others have pointed out your error. (Which your rantings about
volatile merely perpetuate.)
Your mention of (yet more) hardware where the choice of
instruction makes a difference does not run counter to my "as
if" statement, but actually reinforces the unsuitability of
memcpy() for the use at hand. That is, the Standard's only
requirement on memcpy() is that it behave "as if" it copied the
individual bytes; implementations are free to achieve the effect
in any way they please. In particular, they are free to achieve
it in ways that do not play well with pseudo-memory buffers, or
with volatile data in general.
The situation can be even worse: Not only might memcpy() be
unsuitable, but even a plain `x = *p' may be unsuitable. "What
constitutes an access to an object that has volatile-qualified
type is implementation-defined." The practical upshot is that
the mere fact that you use an `int*' to access the buffer is no
guarantee that the compiler will generate the "obvious" int-ish
instruction to fetch from it. It might, for example, helpfully
unroll a loop and then combine two adjacent int accesses into a
single long or long long access, which would be unfortunate if
the pseudo-memory locations were only sensitive to int accesses.
Yes, I have used hardware with such characteristics. And the
last thing I need is individuals who know nothing about my
experience telling me it's inadequate.
