Intel Fortran and ASM code

[Harry_A_]

I apologize if this is not the proper forum for this post.

I encountered a problem iwith an Assembly language (ASM) sorting routine called by Intel Fortran. The ASM routine evidently received its inputs correctly, through its CALL from Fortran, because it did an excellent job of rapidly comb-sorting a very large array. But, instead of returning sampling statistics through its arguments, as I wanted it to, it returned garbage through them.

Now, let's forget the application itself. I have boiled the problem down to a simple set of code. I have eight INTEGER*4 arguments, initially set to values. The ASM code receives the arguments, does nothing (not even a PUSH ESP and POP ESP), and returns. It does not examine the arguments in any way. However, the CALL changes them.

The results are as follows:

Argument 1containsits original value.
Argument 2 contains a long garbage integer.
Argument 3 contains the value that entered through argument 2.
Argument 4 contains 0.
Argument 5 contains the value that entered through argument 3.
Argument 6 contains a garbage integer.
Argument 7 contains the value that entered through argument 4.
Argument 8 contains a garbage integer.

I use Visual Studio .NET 2003 to compile and link. The Fortran program is a Fortran Console application. The project has two files -- the Fortran host program and the .OBJ of the ASM file. For the latter, I assembled with TASM32 and used EDITBIN to convert the format.

With the same code (both Fortran and ASM), the Compaq Fortran compiler (which I am trying to phase out) gives the results I expect. (It returns all arguments, exactly as they were entered.)

What is Intel Fortran doing here thatthe CompaqFortran compiler isn't?

[TimP]

CVF worked with a system similar to the old Windows stdcall, while ifort defaults to the recommended cdecl system of Windows of the last 9 years or so. 32-bit ifort has a CVF compatibility iface option. They differ greatly in caller/callee clean-up responsibities, for example. There's a great deal of searchable material on this, e.g.
http://en.wikipedia.org/wiki/X86_calling_conventions

[Wendy_Doerner__Intel]

Another resource on the calling standard changes please see the section, Default Calling Conventions Have Changed in the migration document:

http://software.intel.com/en-us/articles/migrating-from-compaq-visual-fortran/

This is a good document to read when porting from Compq* Visual Fortran.

Wendy

[Harry_A_]

Quoting - Wendy Doerner (Intel)

Thanks to those who offered help.
I have an acceptable work-around.

On the Fortran side, I define all my arguments as members of a data structure (TYPE) and create a single instance of that TYPE. The Fortran passes only one argument to the ASM, which is the address of the first member of that instance. In the ASM, all of the members are accessed as offsets from that single address, e.g., +0, +4, +8, +12. etc., from that address.

[TimP]

I suppose you mean a sequence type.

[Harry_A_]

I didn't use the word SEQUENCE, but the TYPE is a short list (8 items) of INTEGER*4 items. I have looked at the pointers via LOC( ), and they do differ by 4 bytes, one from another.

[Steven_L_Intel1]

The earlier posts referring to a calling convention change are likely correct. If the routine assumes STDCALL conventions but the caller thinks it is C, or vice versa, you'll corrupt the stack,