ADDA on windows
Michel GROSS
Dear Maxim,
Very happy to receive your response. Of course, I am entirely ready to continue the discussion. As with many software programs available on GitHub, the authors often use Linux and GNU tools along with command-line compilations. Some authors, whom you know well, go further and only code in Fortran under Linux and refuse to do anything under Windows.
As a user, the Linux command-line approach is inconvenient. Everything is based on a script that is completely incomprehensible except to the person who wrote it. If everything works, that's fine, but the novice that I am learns nothing and therefore doesn't understand why it worked. But very often, a detail causes the project construction to fail, and since the novice has learned nothing, he doesn't know how to fix it. Moreover, as an occasional programmer, I use Visual Studio with a Microsoft compiler which, for me, is by far the most powerful tool. That's why I found it simpler, more reliable, and especially more instructive to compile ADDA from scratch with Visual Studio. With the help of ChatGPT doing that is now possible.
Having code in an IDE like Visual Studio 2019 allows you to execute the code step by step, examine the variables, and thus understand how the software works and what it does. If it’s simply about creating a functional executable, it’s easier to get the program in executable form. It's simpler.
During my initial attempts with the Microsoft MSVC compiler, I encountered a multitude of errors because the C99 option is not available in MSVC. Upon closer inspection, the problem seems to stem from the handling of complex operators (+, -, *, /) which is not supported with the complex type defined in <complex.h>. However, the type complex<Type> or double complex <type> defined in <complex> should be usable. Fortunately, the documentation indicates that the Intel C compiler with C99 can work. The Intel compiler works but the Visual Studio tool is then much less powerful.
To illustrate the power of Visual Studio 2019, let's take the example of the problem posed by "_isatty". In which header is "_isatty" found? Impossible to know if the documentation is not up to date. To find out, I selected the MSVC compiler in Visual Studio 2019 (even if it generates multiple errors), I right-clicked on the "_isatty" identifier and in the drop-down menu that appeared, I asked to display the declaration of the "_isatty" function. Visual Studio 2019 opened the "corecrt_io.h" file and displayed the function declaration "_isatty". Thus, I knew that "_isatty" was declared in the <corecrt_io.h> header.
I did the same to find the header where UINT32_MAX was declared.
Regarding the export of functions in a DLL, I asked ChatGPT how to export subroutine BJNDD (n, x, bj, dj, fj) and subroutine propaespacelibreintadda(Rij, k0a,). ChatGPT indicated that I needed to add !DEC$ ATTRIBUTES DLLEXPORT :: BJNDD and !DEC$ ATTRIBUTES DLLEXPORT :: propaespacelibreintadda.
There is a very useful tool under Windows: dllexp.exe "https://www.nirsoft.net/utils/dll_export_viewer.html". This tool provides the list of functions exported in a Windows DLL. This tool shows that a DLL created by IFORT or IFX exports only a very small number of functions, and that these functions are capitalized, whereas mingw64 with gfortran exports all functions, leaves lowercase letters, and adds an underscore.
Regarding oclkernels.cl, I saw the error but didn’t understand it. I asked ChatGPT for help. ChatGPT wrote the "readKernelSource" function and modified the code. I saw that it worked, and I didn't investigate further.
Finally, putting code on GitHub is good, but offering codes with project files for IDEs like Visual Studio would be very useful to users. Only step-by-step execution in an IDE allows for understanding.
Look at what Micromanager does.
Best regards,
Michel GROSS
Maxim Yurkin
First, I fully agree that using an IDE gives a lot benefits. That's why several ADDA developers, including myself, have
been using Eclipse for many years (it allows everything that you mentioned with regards to Visual Studio). This is
described at https://github.com/adda-team/adda/wiki/UsingEclipse , but has not been mentioned in many other places,
since I always believed that most ADDA users want to just compile and run ADDA, or (even better) just run. Now I have
mentioned IDEs in a few more places, and referred to your guide for Microsoft VS, but it is still on the main ADDA page.
I have also updated ADDA code to solve two issues that you uncovered (problem with reading kernel sources at runtime -
https://github.com/adda-team/adda/issues/332 - and inclusion of <stdint.h> in oclcore.c). The latter is good practice
(for full portability), but <stdint.h> was already effectively included by <CL/cl.h> through intermediate cl_platform.h.
This is kind of strange that VS did not found it.
Concerning the _isatty - I still believe that currently included headers are sufficient. Even if VS complains about it,
please try compiling it as is. The Intel compiler should be OK with it (as it strictly conforms to C99 standard).
Finally, the most complicated part is compilation of Fortran sources to the DLLs. While your simple solution works,
there are several reasons why I am reluctant to make it the default for ADDA:
1) DLLs are OS-specific and seems to be an overkill for specific task (here we just need to build a single ADDA
executable, not to have a shared library to be used by many programs). The currently used linking of .obj files works
also on Windows, even when using Intel compiler in combination with VS build tools (as described in iw_compile.bat).
However, I agree that it may be not easy to setup it inside the Visual Studio project.
2) although the proposed additions to the Fortran files are comments, they still may cause compiler warnings
https://fortran-lang.discourse.group/t/standard-conforming-way-of-doing-dec-attributes-dllexport/6523 .
3) I prefer not to touch legacy Fortran files, since once you do it, you need to take some responsibility for them (as
for C code now). And this requires one to understand different Fortran standards and specifically aim for the one in
source files (that is far beyond my current knowledge). Otherwise, there is a danger that some issues will appear when
somebody compiles the code on some system, for which we never tested. This issues can potentially be more serious than
above-mentioned compiler warnings.
4) As an example, aiming at a particular standard, may involve significant amount of effort - see
https://community.intel.com/t5/Intel-Fortran-Compiler/my-Fortran-DLLs-for-my-students/m-p/1453541/highlight/true#M164909
. This is something that I am not ready to do.
To conclude, I ask you to try compile the current ADDA source, using
ifx for Fortran sources (as is)
icx for C sources with preprocessor options (additionally to some VS-specific ones):
NO_GITHASH
propaespacelibreintadda_=PROPAESPACELIBREINTADDA
bjndd_=BJNDD
(for ocl mode additionally)
OPENCL
OCL_READ_SOURCE_RUNTIME
and then link them together using icx.
However, if that it too complicated (in a VS project setup), you may surely keep the DLL approach for Fortran.
The above does not discuss optimization-related compilation flags (to get maximum performance), but that is good (to
avoid them) if you want to debug the code. If you are interested in those, please look inside iw_compile.bat.
Maxim.