Compilers switche questions ... warning long post

[carlls]

Questions about Intel Fortran Compilers:

Versions 8.1 and 9.1

1) Do version 9.1 support decorated function names in EMT64? I.e. _ANINT@4

2) The documentation states that CVF is using STDCALL, I believe this is wrong it uses STDREF, with the addition of all external names being made uppercase. (STDREF is the same as STDCALL EXCEPT pass by reference not pass by value)

Ref. Links:

http://msdn2.microsoft.com/en-us/library/zxk0tw93.aspx

and

http://cache-www.intel.com/cd/00/00/28/46/284698_284698.pdf

So to decompose CVF into its pieces I need.

/iface:stdref

/iface:nomixed_str_len_arg

AND

Make all my routine names uppercase.

This combination supports the classical C/FORTRAN interface, where FORTRAN (77) dictates the following:

1) Routine names uppercase

2) Pass by reference.

3)  ; String lengths at the end.

3) Ifort 10.x calling conventions .from the PDF above

In CVF, the default calling mechanism was STDCALL, and routine

names were decorated by adding @n to the end, where n was the

number of bytes of argument list. Intel Visual Fortran Compiler

adopts the more common C calling mechanism used by versions

7.1 and earlier of the Intel Fortran Compiler. Routine names are

still converted to uppercase by default, and a leading underscore is

added, but there is no @n suffix.

Does this mean the @n suffix is no longer available?

So really #1, is a question is it a bug? For #2, I am looking for confirmation of my findings. And #3 as a software team leader for apps that run on MULTIPLE platforms I kind of liked @n gave me confidence when calling 3rd party libraries. (see below)

My research ( who knows somebody might learn something I did figuring this out)

Sample Fortran code:

subroutine AnInt(i)

return

end

subroutine ADble(a)

real*8 a

return

end

subroutine chk_4_vec(ir,iq,c_id,d,dot,kappa,kn,angle,cross)

integer*4 c_id

real*8 kappa,kn(3),dot,angle,cross(3)

return

end

Compiling this generates the following symbol tables for ifort 8.1 (x86 or 32 bit) on Win XP.

examine chk_4_vec.obj with option Gm (CVF)

-c /Gm /iface:nomixed_str_len_arg

_ANINT@4

_ANINT

_ADBLE@4

_ADBLE

_CHK_4_VEC@36

_CHK_4_VEC

--------------------------------------------

examine chk_4_vec.obj with option stdref

-c /iface:stdref /iface:nomixed_str_len_arg

_anint@4

_anint

_adble@4

_adble

_chk_4_vec@36

_chk_4_vec

--------------------------------------------

examine chk_4_vec.obj with option Gz (STDCALL)

-c /Gz /iface:nomixed_str_len_arg

_anint@4

_anint

_adble@8

_adble

_chk_4_vec@48

_chk_4_vec

(Note: to get the symbols I did

dumpbin /SYMBOLS $1 | grep External | awk '{print $8 }'

)

So from all this it appears STDREF, no mixed string and CAPS matches CVF on win32.

So now I move to cross compile for ifort 9.1 and XP64 cross complication. Using CVF nomenclature.

ifort -c /Gm /iface:nomixed_str_len_arg chk_4_vec.f

Yields the symbols:

ANINT

ADBLE

CHK_4_VEC

Which are undecorated. So what has CVF done? STDREF and uppercase?

By the way a technique to determine if an obj is 32 or 64 bit is .

dumpbin /HEADERS your_code.obj | grep machine | awk '{print $3 }'

In my case .

dumpbin /HEADERS chk_4_vec_64.obj | grep machine | awk '{print $3 }'

yields:

(AMD64)

dumpbin /HEADERS chk_4_vec.obj | grep machine | awk '{print $3 }'

yields:

dumpbin /HEADERS chk_4_vec_64.obj | grep machine | awk '{print $3 }'

yields:

(X86)

Thanks for any input....

Regards

Carl

[TimP]

stdcall, and the CVF variant of it, were never supported by any 64-bit Windows version. The options which support CVF style interfaces don't work with 64-bit compilers (unless they are ignored). Those options were deprecated even before CVF went off support. I thought the standard (default) option was called cdecl, but I'll stay out of any discussion about what you want to call it.

[carlls]

No by all means stay involved, I have codes that run on 5+ platforms. (HP-UX, Cray, Linux, XP,XP64, Sun and SGI)

Traditionally our approach to inter-language programing has been to adopt F77 calling conventions:

1. Uppercase
2. Pass by reference
3. No mixed string length.

This seems to be out the widow....

Now being primarily a "C" guy ( no rotten fruit please) cref, would have been nice 20 yrs ago. But now there is allot of legacy code where the C routines have adapted to the F77 common denominator. ( Is this a case following MS?)

As far as the @nn disappearing I will miss that. It caught a number of cross language issues. Is there anything to take it's place?

So maybe the real questions is this....

In a multiplatform (multiple O/S multiple CPU) environment

Doing cross language linking (C/C++/F77/F90/Java/Tcl)

How does one write a "portable" routine interface? What are the rules? And can it be somewhat consistent across platforms.

Comments please...

Regards

Carl

[TimP]

With release of ifort 10 next week, ifort joins the growing group of compilers supporting f2003 C interoperability. If you have been satisfied with the situation in the past, where the compilers you employed worked with pass by reference, and casing and underscore-appending conventions could be dealt with, the additional portability may not motivate its adoption. C interop apparently doesn't help much with string passing, and still requires "extern C" for those languages which have it.

[carlls]

Hmmmm same basic topic :

http://softwarecommunity.intel.com/isn/Community/en-US/forums/1/30222242/ShowThread.aspx

Funny thing is "connell" and I work together.

From Mr. Lionel (8/16/06)

This was indeed a bug that affected the combination of STDCALL and REFERENCE. Unfortunately, the fix almost certainly won't make our August update but it will be in for September.