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
Received on Mon Mar 29 2010 - 10:30:05 PDT
