is as follows
"
R sets the floating point control word using the R.dll function Rwin_fpset. This sets the FPU to mask all exceptions, use 64 bit precision, and round to nearest or even.
R expects all calls to DLLs (including the initializing call) to leave the FPU control word unchanged. Many run-time libraries reset the FPU control word during initialization; this will cause problems in R, and will result in a warning message like "DLL attempted to change FPU control word from 8001f to 9001f". The value 8001f that gets reported is in the format expected by the C library routine _controlfp; the raw value that is used in the FPU register is 037F.
If you can't tell your compiler to generate a DLL that leaves the FPU alone, then you need to be sure to restore it to R's value before returning to R. See the Delphi section for an example of how to do this in that language. "However, I do not quite follow his method. It seems that the best way is to tell intel fortran to generate a DLL that leaves the FPU alone. How can I do that then? Thanks a lot!
链接已复制
I suppose you could call FOR_GET_FPE at the entry to your DLL, save the value, then call FOR_SET_FPE with that value before returning. That may do the trick. Both of these are documented in the Language Reference.
If you are concerned also about the SSE control, the option /Qftz- (when compiling a Fortran main program) will leave gradual underflow set.
"
is.loaded() returning FALSE
When R uses dyn.load() to load a DLL, it relies on the DLL's export table to find functions. Many compilers use fairly obscure methods to get a function name into the export table. If you don't follow them exactly, your function won't be available to R.
Some compilers (e.g. g77, as mentioned above) make changes to the function names before putting them in the export table. If you specify the original name, R may not be able to find the entry point."do you know how intel fortran get a function name into the export table? Thanks!
There is the notion of a special name for an import library, which is automatically generated by the compiler when you use DLLEXPORT, but that does not apply when doing a dynamic load of the DLL directly, as you are.
Look here
http://www.geocities.com/yongweiwu/stdcall.htm
and see the part about .def which trumps all.
Gerry
The exports being discussed hereare functions/subroutines from a DLL for which .def's arewell suited, that's why Microsoft introduced them and encourages their use.
Up to your assertion,I've never heard of anyone exporting or importing a variable from a DLL, with or without .def. It's not done. Perhaps you're alluding to 'sharing' data as discussed in a different thread. Piff...
Gerry
OK, I'll take you at your word.
So show me howto export a variable from a dl, and I don't mean as an argument of an exported procedure. Here's what I'd like to do:
This is thedll,
subroutine Let()
real x
x = 6.
end subroutine Let
I'd like the variable xto be exported by the dll and nothing else. Feel free touse whatever metacommands you deem necessary. When the client loads the dll it should be aware ofthe type and current value of the variable x.
If you like I, as customer. can submit this toPremier Support but I'm sure you'll be able to handle it off the top.
Thanks
Gerry
module mymod
real x
!dec$ attributes dllexport :: x
contains
subroutine Let ()
!dec$ attributes dllexport :: Let
x = 6
end subroutine Let
end module mymod
Build this into a DLL. Now in your executable project, add:
use mymod
Add to the INCLUDE path of the executable the output directory of the DLL project so that it can see mymod.mod and make the DLL project a dependent of the executable, or add the import library to the executable. Build the executable.
The USE of a module that contains a DLLEXPORT treats it as a DLLIMPORT. The variable and its type will be defined (and the subroutine) as long as you have the USE. I am not sure why you asked for the variable to be exported "and nothing else", though I guess if you are using a .def file you might want to keep that. I'm not sure how .def files mix with DLLIMPORT/EXPORT directives and would suggest you use the directives only.
There is a sample provided, DLLDLL_Shared_Data, which demonstrates this technique.
You can't export a local variable of a subroutine - it has to be something that Fortran considers global. You can also DLLEXPORT a COMMON block.
You are being rude, but what's new!
I never implied that I was using VB, I don't. FYI, dllexport/import isn't partof C anymore than its a part of Fortran. The OP was clearly interested in Fortran portability, something you failed to appreciate.
Gerry
