Yes, but those are not the two compilers I am worried about... We really
need to understand what compilers we intend to support in this release, and
what the impact of the various c preprocessors would be. If we make a
decision to support, say, gcc, intel, pgi, and ibm (the minimal list I can
come up with - I have not a clue about mac's, or how you guys do anything
with cygwin), then so be it. But we should have a list. I used to support
a wide range of stuff for pmemd; I am aware that a lot of those platforms,
especially the risc stuff, are now effectively dead. It would be my guess
that we could use stringizing, but should check it out on all the above
stuff at a minimum (pretty sure no issues with intel or gcc; ibm you never
know). I consider it a clean and good solution, as long as the
preprocessors are there. I suppose one could also insist that on
non-compliant platforms, folks just have to use the gcc preprocessor. But
it has to be worked out...
Scott, do you or does some collective somebody have access to everything
"supported", is there a "supported" list, etc. It would be pretty easy to
check stringizing on some small list of platforms, if you have them...
Regards - Bob
----- Original Message -----
From: "Volodymyr Babin" <vbabin.ncsu.edu>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Monday, March 29, 2010 1:32 PM
Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation using ifort
> Just out of curiosity I tried to compile the following:
>
> example.cc:
>
> extern "C" {
>
> int serious_subroutine() {
> for (int i = 0; i < 1000000; ++i) {
> int j = i*i;
> }
> return 8;
> }
>
> int serious_subroutine_() __attribute__ ((weak, alias
> ("serious_subroutine")));
> int serious_subroutine__() __attribute__ ((weak, alias
> ("serious_subroutine")));
>
> } // extern "C"
>
> using g++ 3.4.6 and icpc 10.1.022 -- in both cases I got
>
> nm example.o
> 00000000 T serious_subroutine
> 00000000 W serious_subroutine_
> 00000000 W serious_subroutine__
>
> which means that icpc does understand __attribute__ (...) and,
> consequently, this can be probably given a try if the problem
> is "to be able to use either gnu or intel compilers to build
> pmemd with CUDA support".
>
> Best,
>
> Volodymyr
>
> On Mon, March 29, 2010 13:03, Robert Duke wrote:
>> Yeah, that is what I am worried about - vendor compilers don't
>> necessarily
>> conform to gcc, so finding stuff to use in gcc is not a great idea.
>> Adhering to certain c standards is a better idea, but I know that at
>> least
>> in the past, the functionality found in c preprocessors was still "hit
>> and
>> miss", to describe it kindly. So we just need to look out for this. If
>> anyone is still using something old, they might try it and see what
>> happens.
>> I used to hit old ibm and and sgi machines for this purpose, but I don't
>> have them anymore.
>> Regards -Bob
>>
>> ----- Original Message -----
>> From: "Volodymyr Babin" <vbabin.ncsu.edu>
>> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
>> Sent: Monday, March 29, 2010 12:37 PM
>> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation using ifort
>>
>>
>>>> The only issue I can think
>>>> of is if there is a c preprocessor out there somewhere that can't
>>>> handle
>>>> stringizing - that may be why I avoided doing this in the first pass.
>>>
>>> A good point to look for a quite portable solution is "gmacros.h" from
>>> glib (http://library.gnome.org/devel/glib/), I believe.
>>>
>>> Another way would be to use gcc's "alias" __attribute__
>>>
>>> http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Function-Attributes.html#Function-Attributes
>>>
>>> alias ("target")
>>> The alias attribute causes the declaration to be emitted as an alias
>>> for another symbol, which must be specified. For instance,
>>>
>>> void __f () { /* Do something. */; }
>>> void f () __attribute__ ((weak, alias ("__f")));
>>>
>>>
>>> defines `f' to be a weak alias for `__f'. In C++, the mangled name
>>> for
>>> the target must be used. It is an error if `__f' is not defined in the
>>> same translation unit.
>>>
>>> Not all target machines support this attribute.
>>>
>>> Just random comments,
>>>
>>> Volodymyr
>>>
>>>> Some
>>>> folks who use a wider variety of platforms than I do might want to
>>>> comment
>>>> on that.
>>>> Regards - Bob
>>>> ----- Original Message -----
>>>> From: "Volodymyr Babin" <vbabin.ncsu.edu>
>>>> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
>>>> Sent: Monday, March 29, 2010 12:18 PM
>>>> Subject: RE: [AMBER-Developers] Help with NVIDIA Compilation using
>>>> ifort
>>>>
>>>>
>>>>> One could possibly use a macro like
>>>>>
>>>>> #ifdef ASSUME_JUST_ONE_TRAILING_UNDERSCORE
>>>>> # define FORTRANIZE(name) name##_
>>>>> #else
>>>>> # define FORTRANIZE(name) name##___
>>>>> #endif
>>>>>
>>>>> or something like that.
>>>>>
>>>>> Best,
>>>>>
>>>>> Volodymyr
>>>>>
>>>>> On Mon, March 29, 2010 11:59, Ross Walker wrote:
>>>>>> Hi Tim
>>>>>>
>>>>>> We already have something similar to this in
>>>>>> src/pmemd/src/cuda/gpu.cpp
>>>>>>
>>>>>> extern "C" void gpu_dump_dval_(double* pDouble)
>>>>>> {
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> I was hoping to find a way to do this without having to go through
>>>>>> and
>>>>>> make
>>>>>> additional copies of everything for Intel.
>>>>>>
>>>>>> All the best
>>>>>> Ross
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
>>>>>>> bounces.ambermd.org] On Behalf Of Timothy J Giese
>>>>>>> Sent: Friday, March 26, 2010 4:15 PM
>>>>>>> To: AMBER Developers Mailing List
>>>>>>> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation using
>>>>>>> ifort
>>>>>>>
>>>>>>> I've only done a few things with cuda/fortran, but I basically
>>>>>>> treat it like how I treat c/fortran, i.e., in C, create
>>>>>>> subroutine_ and have it simply call subroutine.
>>>>>>>
>>>>>>> I've never really thought about pros and cons of this.
>>>>>>>
>>>>>>> For example
>>>>>>>
>>>>>>> void init_template_kernel_drv(int &, int &, int &);
>>>>>>> void free_template_kernel_drv();
>>>>>>> void run_template_kernel_drv(int &, double *);
>>>>>>>
>>>>>>> extern "C"
>>>>>>> {
>>>>>>> void init_template_kernel_(int &, int &, int &);
>>>>>>> void free_template_kernel_();
>>>>>>> void run_template_kernel_(int &, double *);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> void init_template_kernel_(int & max_blocks,int & threads_per_block,
>>>>>>> int
>>>>>>> & buflen)
>>>>>>> {
>>>>>>> init_template_kernel_drv(max_blocks, threads_per_block, buflen);
>>>>>>> }
>>>>>>>
>>>>>>> void free_template_kernel_()
>>>>>>> {
>>>>>>> free_template_kernel_drv();
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> void run_template_kernel_(int & na, double * A)
>>>>>>> {
>>>>>>> run_template_kernel_drv(na, A);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> I found some discussion on the intel boards. Not sure how
>>>>>>> useful it is.
>>>>>>>
>>>>>>> http://software.intel.com/en-us/forums/showthread.php?t=56872
>>>>>>>
>>>>>>> -Tim
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> AMBER-Developers mailing list
>>>>>>> AMBER-Developers.ambermd.org
>>>>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> AMBER-Developers mailing list
>>>>>> AMBER-Developers.ambermd.org
>>>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> AMBER-Developers mailing list
>>>>> AMBER-Developers.ambermd.org
>>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> AMBER-Developers mailing list
>>>> AMBER-Developers.ambermd.org
>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>>
>>>
>>>
>>> _______________________________________________
>>> AMBER-Developers mailing list
>>> AMBER-Developers.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Mar 29 2010 - 11:00:04 PDT
