Does LLVM Fortran compiler (similar to GNU or Intel) provide a function getpid() or its equivalent to return the process identifier?
There is nothing simpler then opening the compiler's page and check the manual, or the source code. In this code it was actually faster to check the Github project, it is certainly faster than asking at StackOverflow... The getpid function is there among all other intrinsics https://github.com/flang-compiler/flang/tree/master/runtime/flang . Specifically, it is (non surprisingly) in the sourcefile that starts wth getpid... https://github.com/flang-compiler/flang/blob/master/runtime/flang/getpid3f.c
And then you can simply clone the project and try find . -type f | xargs grep -in "getpid" to find even more locations or even build the compiler and try the Fortran code.
Related
Chisel provides the printf function for debugging purposes, when generating verilog, it becomes fwrite system function. How to use verilog simulation to output data to a file instead of the terminal only when the chisel code is modified. Can chisel's printf function do this?
The short answer appears to be no. But there are two issues filed about this
Can chisel implement printf to a file? #1290
Feature Request: Allow printfs to go to different file descriptors #1287
It might be a good PR to submit.
I would like to do the equivalent of exec in sh, or execve(2), just transfer control from tcl to a called command and never return, so that any signals sent to what used to be the tcl process go directly to the called command, stdout of the called command is the stdout of what used to be the tcl process, etc.
I have looked around in the manuals, but haven't found an obvious way to do this in tcl.
I'm not talking about tcl's exec, which keeps tcl running, creates a subprocess and captures its output, then resumes control flow in the tcl process.
There's nothing built into Tcl itself at the moment, but the TclX extension includes a command, execl, which can do exactly what you want.
package require TclX
execl /bin/bash [list -c somescript.sh]
Note that doing an execl that fails may put the process in an inconsistent state, as some libraries use hooks to detect the underlying system call and close their resources. It depends on exactly what you're doing of course, but since the X11 library is a notable example of this, Tk applications are unsafe to continue the current process with if execl fails. (The fork/execl idiom — or Tcl's standard exec — doesn't have the problem, as the problem syscall always happens in a subprocess.)
My understanding of TCL execution is, if a command's compile function is defined, it is first called when it comes to execute the command before its execution function is called.
Take command append as example, here is its definition in tclBasic.c:
static CONST CmdInfo builtInCmds[] = {
{"append", (Tcl_CmdProc *) NULL, Tcl_AppendObjCmd,
TclCompileAppendCmd, 1},
Here is my testing script:
$ cat t.tcl
set l [list 1 2 3]
append l 4
I add gdb breakpoints at both functions, TclCompileAppendCmd and Tcl_AppendObjCmd. My expectation is TclCompileAppendCmd is hit before Tcl_AppendObjCmd.
Gdb's target is tclsh8.4 and argument is t.tcl.
What I see is interesting:
TclCompileAppendCmd does get hit first, but it is not from t.tcl,
rather it is from init.tcl.
TclCompileAppendCmd gets hit several times and they all are from init.tcl.
The first time t.tcl executes, it is Tcl_AppendObjCmd gets hit, not TclCompileAppendCmd.
I cannot make sense of it:
Why is the compile function called for init.tcl but not for t.tcl?
Each script should be independently compiled, i.e. the object with compiled command append at init.tcl is not reused for later scripts, isn't it?
[UPDATE]
Thanks Brad for the tip, after I move the script to a proc, I can see TclCompileAppendCmd is hit.
The compilation function (TclCompileAppendCmd in your example) is called by the bytecode compiler when it wants to issue bytecode for a particular instance of that particular command. The bytecode compiler also has a fallback if there is no compilation function for a command: it issues instructions to invoke the standard implementation (which would be Tcl_AppendObjCmd in this case; the NULL in the other field causes Tcl to generate a thunk in case someone really insists on using a particular API but you can ignore that). That's a useful behaviour, because it is how operations like I/O are handled; the overhead of calling a standard command implementation is pretty small by comparison with the overhead of doing disk or network I/O.
But when does the bytecode compiler run?
On one level, it runs whenever the rest of Tcl asks for it to be run. Simple! But that's not really helpful to you. More to the point, it runs whenever Tcl evaluates a script value in a Tcl_Obj that doesn't already have bytecode type (or if the saved bytecode indicates that it is for a different resolution context or different compilation epoch) except if the evaluation has asked to not be bytecode compiled by the flag TCL_EVAL_DIRECT to Tcl_EvalObjEx or Tcl_EvalEx (which is a convenient wrapper for Tcl_EvalObjEx). It's that flag which is causing you problems.
When is that flag used?
It's actually pretty simple: it's used when some code is believed to be going to be run only once because then the cost of compilation is larger than the cost of using the interpretation path. It's particularly used by Tk's bind command for running substituted script callbacks, but it is also used by source and the main code of tclsh (essentially anything using Tcl_FSEvalFileEx or its predecessors/wrappers Tcl_FSEvalFile and Tcl_EvalFile). I'm not 100% sure whether that's the right choice for a sourced context, but it is what happens now. However, there is a workaround that is (highly!) worthwhile if you're handling looping: you can put the code in a compiled context within that source using a procedure that you call immediately or use an apply (I recommend the latter these days). init.tcl uses these tricks, which is why you were seeing it compile things.
And no, we don't normally save compiled scripts between runs of Tcl. Our compiler is fast enough that that's not really worthwhile; the cost of verifying that the loaded compiled code is correct for the current interpreter is high enough that it's actually faster to recompile from the source code. Our current compiler is fast (I'm working on a slower one that generates enormously better code). There's a commercial tool suite from ActiveState (the Tcl Dev Kit) which includes an ahead-of-time compiler, but that's focused around shrouding code for the purposes of commercial deployment and not speed.
My program consists of a Matlab file (.m) and a mex-cuda file(.cu). It starts with Matlab, then the Matlab file calls the mex-cuda file.
I want to get profiling the performance in the mex-cuda file using 'nvprof' command-line. I know that for regular CUDA program, we simply use (in Unix):
$nvprof file.out
However, the mex-cuda file now is called from matlab, not from the shell anymore. Is there a way to use 'nvprof' command-line for this mex-cuda file?
If you run matlab from the command line, try
nvprof "matlab < myfile.m"
The quotes may be unnecessary, i.e.this may work as well:
nvprof matlab < myfile.m
This blog explains how to profile CUDA kernels from MATLAB.
http://meerkat.gr/matlab-profile-cuda.html
It should work with CUDA-MEX as well.
Hey there,
if the env var "XYZ" is set WHILE compiling, than I want the part:
write (STDOUT,*) "Compiled with XYZ"
here one more function call bla()
to be compiled into the binary. If not, than not.
Any way to do it?
Thanks a lot!
You can't check environment variables while compiling, but you can pass options to the compiler -- termed preprocessing. This isn't heavily documented, but works with at least gfortran and intel ifort. On the compile line use, or not, "-DMYOPTION" (or whatever option name you select). Then in the code:
#ifdef MYOPTION
Fortran source code
#else
Fortran source code
#endif
Apparently that the preprocessor lines must start in the first column.
If you use filetype "F90" the preprocessor will be automatically invoked, otherwise you can use a compiler option to invoke this step.
Maybe this will answer your need? If not, you could you a command script to check the environment variable and use different compile commands depending on its value, to make the preprocessor method respond to an environment variable.
Of course, you can check environment variables at run-time with the intrinsic get_environment_variable .. simply using if statements to respond to a value might be easier.
As part of the Fortran 2008 standard, there are intrinsic functions for finding the compiler options and version it was compiled with. compiler options and compiler version. Fortran compilers are slowly coming up to date with the new standard; gfortran has it, it doesn't look like ifort 12 does yet:
program compilerinfo
use iso_fortran_env
implicit none
print *,'This program was compiled with ', compiler_version()
print *,'with flags ', compiler_options()
end program compilerinfo
and running gives
$ ./compilerinfo
This program was compiled with GCC version 4.6.0
with flags -mtune=generic -march=x86-64
NoOnly very newest Fortran compilers provide such a feature.
The nearest mechanism would be to write a program which obtains the environment variable and writes a Fortran subroutine containing the information needed. Add to the project build:
Running the program to grab the environment variable and write the subroutine
Compile the subroutine
Link the object into the rest of the project.
Edited to reflect Fortran 2008+ compilers