Okay, I have not messed with the nvidia stuff yet, but there is a convention
in pmemd already for getting the correct fortran to c linkage, embedded in
the pmemd_clib.c code. Given that there are potentially a lot of
fortran --> c calls potentially for cuda, then a macro like Volodomyr
recommends here might be a pretty good idea, though, with the macro defined
in place of the hardcoded names in pmemd_clib.c. 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. 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
Received on Mon Mar 29 2010 - 09:30:05 PDT
