Re: Defeating Optimisation for memcmp()

Martin wrote:
"James Kuyper" <jameskuyper@xxxxxxxxxxx> wrote:
Let me say this frankly: what you say you want to do is pointless, for precisely the same reason that you can't prevent the optimization. If there's really a point to what you want to do, you haven't made that clear. You need to expand your description of the problem to make that point clear; as soon as you do so, we can tell you what to do to prevent the optimization.

What I want to do is far from pointless. When I wrote "I want to write code that will verify that a write to CMOS has succeeded, and ensure that the compiler does not optimise away the verification" that's exactly what I wanted to do.

The detail is simply that the code is writing to CMOS (hence the variable names derived from it). CMOS is an area that has a limited number of writes available to it (I assumed this was fairly common knowledge). After a certain amount of use, writes can, do, and have been failing. The code has not been detecting that and now we've decided it must. We need to tell the compiler that it mustn't assume that a write to CMOS has succeeded (using memcpy or whatever) - it *must* perform the verification, using memcmp, or whatever. It's basically a memory test.

The only reason I can think of for your comments is that you were assuming I wanted to check the write because I wasn't confident that memcpy was implemented correctly. As I have now explained, it's because the CMOS may be failing.

You said that the memory being pointed at was not volatile. My comments were predicated on taking you at your word. Now you've described that memory in a fashion that has to be described as volatile.

The best solution you can use in that case has already been mentioned: instead of using memcmp(), write your own version that takes pointers to volatile as arguments. It's pretty trivial to do. The reason the standard memcmp() is not written that way is that in general its output would be pretty meaningless: since the pointed-at memory is volatile, the only thing the return value from volatile_memcmp() would tell you is how the bytes compared at the times that they were compared. Inherently, different bytes are necessarily compared at different times, so it cannot even be considered a snapshot comparison.

However, if you assume that the memory you're looking at is changing sufficiently slowly, volatile_memcmp() could be a useful and meaningful thing to define.
.

Relevant Pages

  • Re: Defeating Optimisation for memcmp()
    ... precisely the same reason that you can't prevent the optimization. ... The detail is simply that the code is writing to CMOS (hence the variable ... The only reason I can think of for your comments is that you were assuming I ... wanted to check the write because I wasn't confident that memcpy was ...
    (comp.lang.c)
  • Re: Defeating Optimisation for memcmp()
    ... precisely the same reason that you can't prevent the optimization. ... The detail is simply that the code is writing to CMOS (hence the variable ... The only reason I can think of for your comments is that you were assuming ... The volatile keyword is what you need. ...
    (comp.lang.c)
  • Re: M848A motherboard
    ... as (wrong cmos settings/ wrong memory size) and for some reason the ... You've got a defective motherboard. ...
    (alt.comp.hardware.pc-homebuilt)
  • Re: Im building a new gaming PC, I was wondering if I could get some hints....
    ... The same memory modules will do. ... The reason I used the 4gb 2gb kit, is so that i wont waste money when ... because my motherboard only supports that kind... ... the 5 case fans, not fully needing to be annoying me all the time... ...
    (alt.comp.hardware.pc-homebuilt)
  • [PATCH -mm 1/5] Freezer: Document relationship with memory shrinking
    ... allocate memory after freeing it for the hibernation image, ... The majority of these are user space processes, but if any of the kernel threads ... The second reason is to prevent user space processes and some kernel threads ... +memory and we need to do that before ...
    (Linux-Kernel)