<br><br><div class="gmail_quote">On Mon, Jul 26, 2010 at 4:06 PM, Sander Pronk <span dir="ltr"><<a href="mailto:pronk@cbr.su.se">pronk@cbr.su.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">I just checked, and MSVC does appear to support more than 3 __m128 parameters if parameters 4 and up are pointers. Your solution would probably work, but we'd be working around - and introducing additional complexity for - a braindead compiler, on a platform where icc does the right thing.</div>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><br></div><div>The other issue with MSVC is that it doesn't support fftw: we might as well require icc+mkl or cygwin for Windows. People who use Windows and insist on the MSVC development environment are probably used to paying for their compiler and OS anyway... <br>
</div></div></blockquote><div>FFTW works without problems with MSVC. One can download a binary on the FFTW website and this works. They claim one can also compile it with MSVC but I haven't tried.</div><div>I don't mind cygwin but it is terrible slow. And don't really want to get ICC just for occasional testing on Windows (of course mainly use Linux thus MSVC Express is nice). But it is not such a big problem. I got the 64bit version to compile under MSVC.</div>
<div><br></div><div>Thus I probably agree that the solution adds to much complexity if it is just for MSVC on Win32. I understood the rant as a plan to modify every functions with more than 3 parameters to macros. And I think my proposed solution is better than using macros instead of inline functions. Thus I suggest to leave it like it is but go with my solution and not macros if we decide we want to support MSVC+Win32.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div><div>Once C++ is allowed, the easy solution would be to make those parameters const references, so there's no need to change the calling code.</div>
</div></div></div></blockquote><div>That's true.</div><div><br></div><div>Roland</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">
<div><div><div><div><div><div><div><div><div><div></div><div class="h5"><div>On Jul 26, 2010, at 07:00 , Roland Schulz wrote:</div><br></div></div><blockquote type="cite"><div><div></div><div class="h5">Hi,<div><br></div>
<div>gmx_sse2_single.h doesn't compile with MSVC 2010 on 32bit. As the COMPILER RANT in the file states MSVC doesn't support more than 3 __m128 parameters. </div><div>In the rant it also says that some compilers don't support pointers to __m128. For what compiler is this still true? If none, I suggest to change the arguments to const pointers.</div>
<div><br></div><div>If there are still, some: Are there also compilers which don't support either pointers nor unlimited __m128 parameters?</div><div><br></div><div>If not, I suggest a mixed approach. Where we detect which version is supported and use macros to have to write each function only once. See the below example. I think this is much less error prone than converting all functions to macros as the rant suggests. Mainly because of the double evaluation pitfall of macros. </div>
<div><br></div><div>Roland</div><div><br></div><div>sample:</div><div><div>#include <xmmintrin.h></div><div><br></div><div>#ifdef SSE_POINTER</div><div>#define SSE_M128(a) const __m128 *a</div><div>#define SSE_REF(a) (&a)</div>
<div>#define SSE_IND(a) (*a)</div><div>#else</div><div>#define SSE_M128(a) __m128 a</div><div>#define SSE_REF(a) (a)</div><div>#define SSE_IND(a) (a)</div><div>#endif</div><div><br></div><div>static inline void f(SSE_M128(b)) {</div>
<div> __m128 x = SSE_IND(b);</div><div>}</div><div><br></div><div>int main() {</div><div> __m128 x;</div><div> f(SSE_REF(x));</div><div> return 0;</div><div>}</div><div><br></div></div><div><br></div><div><br>-- <br>
ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov/" target="_blank">cmb.ornl.gov</a><br>
865-241-1537, ORNL PO BOX 2008 MS6309<br>
</div></div></div>
-- <br>gmx-developers mailing list<br><a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br><a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the <br>www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div>
<br></div></div></div></div></div></div></div></div><br>--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br><br clear="all"><br>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>
865-241-1537, ORNL PO BOX 2008 MS6309<br>