<div dir="ltr">On Tue, Nov 25, 2014 at 5:16 AM, Cownie, James H <span dir="ltr"><<a href="mailto:james.h.cownie@intel.com" target="_blank">james.h.cownie@intel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From a runtime point of view we need to preserve backwards binary compatibility, so we can't change the interface to the current interface function to introduce a count (because that old code won't set it).<br></blockquote><div><br></div><div>Okay.  I wasn't sure if you were guaranteeing backwards binary compatibility with existing compiles or not.  The way that I understand you're currently deploying the runtime — linking in a static library that's distributed with the compiler — does not actually require backwards binary compatibility as far as I can tell.  But if you're making that guarantee, then I agree we can't break it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would therefore prefer to do this<br>
<br>
1) Change the prototype for the existing function so that it becomes a function with no arguments. (Effectively your #1). Since no existing code passes arguments, this is fine.<br></blockquote><div><br></div><div>Changing from a variadic to a non-variadic function is technically allowed to break the ABI, e.g. by passing the non-optional arguments in a different way.  I don't know of any platforms where it does actually change for the standard C calling convention, though — I know of platforms (like MIPS and Apple's ARM64) that change how variadic arguments are passed, but not of any that affect earlier arguments.  And I *think* there's no issue with new compilations calling old runtimes on platforms like x86-64 where variadic functions expect extra information, because I don't know of any compilers that actually crash on an out-of-range value in %al.</div><div><br></div><div>So this is probably fine, but if you want to be 100% paranoid, the safest thing to do is to leave it variadic but document that the variadic arguments are useless.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) If/when we decide that it is useful to pass extra information, we design that as a new function. I can't see a need for that in a cache-coherent system, and in a non-coherent system the interface needs to be more complicated than just a set of pointers (because you also need to know how big the object at the target of the pointer is). So this gets complicated, but, since we're not going to implement it until we need it and understand the problem better, that’s fine. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm avoiding your #2 because I don't believe it is sufficient.<br></blockquote><div><br></div><div>I'm fine with that decision; it's your call.  I hadn't looked to see what these pointers were supposed to be; I guess I was assuming that they were variable descriptors or something, not literally just pointers to objects of unknown size.</div><div><br></div><div>It sounds like the flush operation is really designed for the benefit of OpenMP implementations that aren't just using CPU threads.  Given that your runtime's API is really only designed to be good enough for CPU threads, there's no reason to future proof it, because current CPUs don't let us do efficient partial memory barriers anyway.  If somebody comes out with a CPU that does, we can embellish the API then.</div><div><br></div><div>John.</div></div>
</div></div>