inline Assembler

[oh_moose]

Does the Intel Fortran compiler for Linux support inline Assembler code, like the IBM Fortran III (1958) compiler, or is there a plan to include this feature very soon?

[jimdempseyatthecove]

Don't know what Intel plans are for IVF. My usual methods are

Compile .F90 file with optimizations as desired and produce/keep assembler file.
Edit assembler file as desired.
Exclude .f90 source file from build
Add the .asm file to build (so repeated edits will compile)

The above is for inline code.

For out of line code the argument passing may vary so I might use a shell .F90 subroutine/function to generate the firs cut of the .ASM file.

Or write the subroutine/function in C++

Jim Dempsey

[oh_moose]

Hi Jim, glad to see that I am not the only person who is manipulating assembler output of the compiler. I use this method to change references to common blocks in legacy libraries, those with the (stupid) trailing underscore (for the routines in the legacy libraries I use a bunch of hooks with "jmp" from the version w/o _ to the version w/ _ in the legacy libraries). Hopefully nobody will ever check my build procedure until I get all the legacy libraries addressed.

There are other situations where inline Assembler code is useful. I hope the good folks at Intel listen.

[TimP]

There was a general policy to shift away from supporting asm (even for C) and use the SSE intrinsics instead, so as to have a degree of compatibility between 32-bit and the various 64-bit architectures, and between Windows and linux compilers. The Fortran compilers for x86-64 which do support these intrinsics directly in Fortran haven't found them popular enough with customers. In my personal opinion, I don't expect Intel Fortran to lead in that direction, but rather to continue to depend on C or asm function calls.

[Steven_L_Intel1]

The Intel Fortran team has no plans to support inline assembler nor instruction intrinsics a la C. The SSE intrinsics are more useful in C since it does not have the intrinsic concept of arrays. Other things Intel C does with intrinsics, such as prefetch hints, are done with directives in Intel Fortran.

[jimdempseyatthecove]

Steve,

Could you suggest to the development team that some C-like intrinsics would be welcome in IVF. An example of whichis MFENCE. It would be nice not to have to call a C/C++ function to perform such an operation. It wouldn't hurt for both compiler teams to get together to discuss the intrinsics adopted by C/C++ and the motivations for doing so.

Jim

[Steven_L_Intel1]

Jim, the intrinsics are widely viewed, even by the C++ team, as a hack, and the Fortran developers want no part of it. I am not really familiar with all the possible intrinsics - if you have a case you can make for a particular function such as MFENCE, please submit a feature request to support. Don't get your heart set on an intrinsic, but there may be other ways to accomodate it.

[jimdempseyatthecove]

Would you consider it a hack to make program statements perform as intended or would you consider it a hack to CALL an external subroutine to make program statements perform as intended?

Consider an example that is not too unrealistic. Let's say a multi-threaded application written WITHOUT OpenMP where you wish, as an example, store data into a buffer, then write an indicator into a flag variable. It is a requirement to assure that the all the data is written into the buffer (through to RAM)_prior_ to the flag being written (through to RAM). To accomplish this, placing an MFENCE between the last write of the buffer data and the writting of the buffer full flag would suffice.

Since an MFENCE intrinsic is not available one must resort to performing a CALL to C function to perform the MFENCE, or call an alternate function that has the side effect of performing the MFENCE.

Note, when compiling WITH OpenMP you have available the compiler directive !$OMP FLUSH var which is intended to provide this type of functionality. But unfortunately this results in the calling of a function the mearly returns. i.e. there is no fencing operation. A waste of processor time to perform a call to a no-op subroutine.

Note, the testing of !$OMP FLUSH may have tended to pass your test suite due to introducing a delay but it does not specifically cause a flush/fencing operation and thus fails occasionally in my applications. What !$OMP FLUSH does do is assure registerized variables are written, but in this case written means into the cache and not through to RAM, and not with regard to sequencing. Writes to RAM are not assured to occure in the order in which the instructions appeared to have been execuited (i.e. in the order in which the instruction fetch occured).

There is also a similar problem with !$OMP ATOMIC not working correctly all the time. (It works correctly most of the time, like while you are trying to debug a failure).

Yes, this was reported several years ago, no fix, I quit bothering myself with pushing this issue as I use other means to assure the consistency of the memory.

I don't have my heart set on Intel introducing intrinsic functions.

That said, an intrinsic function is NOT part of the Fortran standard. An intrinsic function can be a vendor supplied library function, but where the vendor's compiler knows what is in the function and therefore can place the equivilent functionality in-line.

Jim Dempsey