I mean this module : Option
I can't find it, open Option gives me Error: Unbound module Option and there is no 'option.cma' file
Is it in the standard library ? Is it named 'option.cma' ?
This is not part of the OCaml standard library, no. It looks like it might be part of a former library named Extlib. Extlib, in turn, seems to have become part of OCaml Batteries Included. The Option module is now named BatOption.
If you want this module, you should get OCaml Batteries Included. Then you need to tell the OCaml compiler how to find the library. It will be explained in the installation instructions for Batteries.
Related
I have a Fortran code which has been made to work on CPUs, but I need to accelerate it using GPUs and I chose to do that with OpenACC.
This code uses FFTW libraries when compiled with gfortran. However, as you may know, these libraries cannot be used with nvfortran. So, I have to go with cufft libraries.
Therefore, I used this conversion giude. The problem is, fftw allows users to build a Fortran module with iso_c_binding including the file fftw.f, while cufft does not have this kind of feature and you need to include the cufft.h header.
When compiling with nvfortran (I use -cpp, -Mfree, -lcufft and -l cufftw flags, checked the include and lib directories given to -I and -L flags) I get many errors:
The paths in all the #include inside the cufft.h file are wrong and I had to change them manually
All the comments ("//") in the header files are seen as errors (had to remove them manually)
“Label field of continuation line is not blank” errors everywhere in header files, starting from line 2 (in lines 1 I solved that giving 7 spaces - but didn’t I use -Mfree for that?)
Please help me, I don’t think that the right way to do so is to change files manually…
Thanks in advance for helping
You cannot include headers for the C programming language in Fortran source code. Instead use the Fortran interfaces to any libraries you need (provided such interfaces exist).
We ship a cuFFT interface module with the compilers. You should just be able to add "use cufft".
Full documentation can be found at: https://docs.nvidia.com/hpc-sdk/compilers/fortran-cuda-interfaces/index.html#cf-fft-runtime
Example codes are shipped with the NVHPC SDK which can be found in the "<INSTALL_DIR>/Linux_x86_64/<RELEASE>/examples/CUDA-Libraries/cuFFT/"" directory
There are submodules in the module Stdlib. How can I access them? For example, the natural Stdlib.Fun.id causes
Error: Unbound module Stdlib.Fun
There are a lot of tutorials on OCaml module system, but they all consider only one level of hierarchy. At least, I did not found otherwise.
You access them exactly like that. The error message says that Stdlib.Fun does not exist. Stdlib.Fun was added in 4.08, and Stdlib itself was added in 4.07 (before that you could only reference the standard library modules directly). Therefore, if you use a version of OCaml older than 4.08, this specific invocation won't work.
At time of writing, the latest version of the compiler is 4.10. You might want to upgrade to that to avoid further surprises like this.
I have a module module1 in a file called mymodule.f90. What should I do in order to make module1 usable like fortran intrinsic module?, i.e. it need only be called in a use statement (use module1) in any programs, subroutines, or functions that use it but I don't need to link /path/to/mymodule/ when compiling those procedures.
I use gfortran, but possibly in the future I will also have to use the Intel fortran compiler.
So maybe I'm misunderstanding you, but you want to use a module without having to tell the compiler where to find the .mod file (that contains the interface definitions for whatever module1 exports), or the linker where the object code can be found?
If so, for GFortran the solution is to download the GCC source code, add your own module as an intrinsic module, and then build your own custom version of GFortran. As a word of warning, unless you're familiar with the GFortran/GCC internals, while this isn't rocket science, it isn't trivial either.
For Intel Fortran, where you presumably don't have access to the source code of the compiler, I suppose you're out of luck.
My suggestion is to forget about this, and instead tell the compiler/linker where your .mod files and object files can be found. There are tools like make, cmake etc. that can help you automate this.
When you compile mymodule.f90 you will obtain an object file (mymodule.o) and a module file (mymodule1.mod). The compiler needs to have access to the module file when it compiles other files that use mymodule1, and the linker needs to have access to the object file when it generates the binary.
You don't need to specify the location of intrinsic modules because they are built in into the compiler. That will not be the case with your modules: you may be able to set up your environment in a way that the locations of your files allow the compiler to find the files without explicitly specifying their paths in compilation or linking commands, but the fact that you don't see it does not mean it's not happening.
For the Intel compiler, the answer is given by https://software.intel.com/en-us/node/694273 :
Directories are searched for .mod files in this order:
1 Directory of the source file that contains the USE statement.
2 Directories specified by the module path compiler option.
3 Current working directory.
4 Directories specified by the -Idir (Linux* and OS X*) or /include (Windows*) option.
5 Directories specified with the CPATH or INCLUDE environment variable.
6 Standard system directories.
For gfortran I have not found such a clear ordered list, but relevant information can be found in
https://gcc.gnu.org/onlinedocs/gfortran/Directory-Options.html
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options
It should be clear to you that a compiler won't be able to understand module files created by other compilers, or even by different enough versions of the same compiler. Therefore, you would need a copy of your "always available" module for each compiler you use, and if you are using multiple versions of a compiler you may need up to one per version - each of them in a different directory to avoid errors.
As you can see, this is not particularly practical, and it is indeed far from common practice. It is usually easier and more clear to the user to specify the path to the relevant module file in the compilation command. This is quite easy to set up if you compile your code using tools such as make.
Finally, remember that, if you make such arrangements for module files, you will also need to make arrangements for the corresponding object files at the linking stage.
Is there a tool that expands verilog modules as much as it can?
For example:
module and_gate(...);
/* module description ... */
endmodule
module test(...);
and_gate and1(...);
endmodule
In that example I would like the and_gate instance and1 in the test module to expand to the module description with the necessary modifications so that the module would compile (maybe prefix every element with the name of the instance, etc.).
I am not aware of any tool that can do that, because:
The synthesis process already does that: when a module is "called" from within another, that module is actually instantiated. That is, its contents (and the contents of any module that this module "calls" to) are included in the upper module
For simulation, you want meagninful names for your nets and modules so your wave traces are easy to read and your possible mistakes easy to spot. Any tool that mangles net names so nets in simulations don't match nets in your design will give you a lot of headaches
Anyway, I recall that Verilog functions and tasks behave mostly the way you ask. So do modules, but you won't get an updated source code with the expansion performed.
I would like to be able to share a FORTRAN 95 module without sharing its source code. Is it possible to do so (maybe by sharing the .MOD file)? In case this is relevant, I use Silverfrost FTN95 compiler on Plato. So far, I only manage to make this work by using the source code of the external module. Here is an example:
file: module_test.f95
module TEST
contains
subroutine 1
code...
end module TEST
file: main_program.f95
include "module_test.f95"
program MAIN_PROGRAM
use TEST
implicit none
code...
end program MAIN_PROGRAM
So, would it be possible for someone to use my module TEST without having my file module_test.f95 nor the line include "module_test.f95" on the main code?
Thanks a lot!
You could provide two things. 1) Compiled object code, possibly in library form. The disadvantage is that this would depend on compiler, OS, perhaps compiler version, and so could be large burden to support. 2) Instead of providing the source code so that others could use the module, you could write equivalent interface descriptions of your routines. This, at least, is at the source code level and would not be compiler dependent. It would some work to write and would have to be maintained if you changed the arguments of any of your procedures.
The solution I am using is, as M. S. B. recommended, to compile the module in library form. I am explicitly showing how I am doing this in case this might be helpful to someone, as this is what I did not know in those days.
First, one needs to compile the module module_test.f95. Using the gfortran compiler, this can be accomplished by the command gfortran -c module_test.f95. This will create two files, module_test.o and module_test.mod. These are the compiled module files that can be shared without sharing the source code.
Now to the main program. For it to make use of the module, one still needs to add the line use TEST but no include <source code>:
program MAIN_PROGRAM
use TEST
implicit none
<...code...>
end program MAIN_PROGRAM
Now when compiling the main program, one must include the location of the .o module file in the command. In the case above, it would be gfortran main_program.f95 module_test.o (supposing that module_test.o is on the same folder as the project). This will compile the main program using the module without the need for its source code.