From: Richard Maine on 8 Dec 2009 12:17 aeroguy <sukhbinder.singh(a)gmail.com> wrote: [quoting something, from context, possibly IVF docs] > " > In a single-language program, calling conventions are nearly always > correct,.... Exceptions exist, though I suppose that the "nearly always" does allow exceptions and is accurate enough. The exceptons that come to mind are 1. "Single-language" does not mean "single-compiler". There are plenty of contexts where there is reason to try to mix comiled code from different compilers for the same language. For example, a library might be compiled with a different compiler because it came from a vendor who uses a different compiler than you do, or if you use multiple compilers, just because you don't want to maintain corresponding multiple versions of the library. I've seen both of those cases. There are differences in calling conventions among compilers for the same language. Variation in the placement of the "hidden" argument for string length is one simple Fortran example. 2. Perhaps unfair in a way, but I have seen it happen and result in questions here... Sometimes people bring the trouble on themselves. I've seen people take a perfectly fine procedure and call to it, but then add compiler directives to try to "fix" some unrelated problem (having misidentified where the problem is) and manage to explicitly tell the caller and callee to use different conventions. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: user1 on 9 Dec 2009 11:15 aeroguy wrote: [snip] > > I am still experimenting and trying to get at the root of this > problem. > > Looking at the code provided, could this be the problem. > > Any ideas? I'm not sure I can help you with IVF, but I think I got it working with the gfortran / mingw from www.equation.com Here is the fortran code (fortrandll.f90) - Subroutine FortranDLL( Array1, upbound ) Implicit None ! ...argument declarations Integer :: upbound Integer :: Array1(1:upbound) ! Local variables Integer :: i do i=1,upbound Array1(i)=Array1(i)+10 end do End Subroutine FortranDLL It was compiled like this - (notice the -mrtd option) gfortran -mrtd -fno-underscoring -shared -o fortrandll.dll -Wl,--export-all,--out-implib,fortrandll.a fortrandll.f90 And here is the VBA code that called it - (notice passing test(0) by reference !!) Declare Sub fortrandll Lib "C:\TEMP\fortrandll.dll" (ByRef Array1 As Long, ByRef upbound As Long) Sub Button1_Click() Dim II As Long Dim test(5) As Long For i = 0 To 5 test(i) = i * 1 Next i II = 6 Call fortrandll(test(0), II) Range("a1").Value = test(0) Range("a2").Value = test(1) Range("a3").Value = test(2) Range("a4").Value = test(3) Range("a5").Value = test(4) Range("a6").Value = test(5) End Sub
From: aeroguy on 10 Dec 2009 02:45 On Dec 9, 9:15 pm, user1 <us...(a)example.net> wrote: > aeroguy wrote: > > [snip] > > > > > I am still experimenting and trying to get at the root of this > > problem. > > > Looking at the code provided, could this be the problem. > > > Any ideas? > > I'm not sure I can help you with IVF, but I think I got it working with > the gfortran / mingw fromwww.equation.com > > Here is the fortran code (fortrandll.f90) - > > Subroutine FortranDLL( Array1, upbound ) > Implicit None > ! ...argument declarations > Integer :: upbound > Integer :: Array1(1:upbound) > > ! Local variables > Integer :: i > > do i=1,upbound > Array1(i)=Array1(i)+10 > end do > > End Subroutine FortranDLL > > It was compiled like this - (notice the -mrtd option) > > gfortran -mrtd -fno-underscoring -shared -o fortrandll.dll > -Wl,--export-all,--out-implib,fortrandll.a fortrandll.f90 > > And here is the VBA code that called it - (notice passing test(0) by > reference !!) > > Declare Sub fortrandll Lib "C:\TEMP\fortrandll.dll" (ByRef Array1 As > Long, ByRef upbound As Long) > > Sub Button1_Click() > > Dim II As Long > Dim test(5) As Long > > For i = 0 To 5 > test(i) = i * 1 > Next i > II = 6 > > Call fortrandll(test(0), II) > > Range("a1").Value = test(0) > Range("a2").Value = test(1) > Range("a3").Value = test(2) > Range("a4").Value = test(3) > Range("a5").Value = test(4) > Range("a6").Value = test(5) > > End Sub Yes this is working in gfortran. thanks. i will test similar options in intel fortran and report back. thanks again.
From: Jugoslav Dujic on 10 Dec 2009 03:51 aeroguy wrote: > On Dec 9, 9:15 pm, user1 <us...(a)example.net> wrote: >> aeroguy wrote: >> >> [snip] >> >> >> >>> I am still experimenting and trying to get at the root of this >>> problem. >>> Looking at the code provided, could this be the problem. >>> Any ideas? >> End Sub > > Yes this is working in gfortran. thanks. i will test similar options > in intel fortran and report back. FYI, Intel fortran uses __cdecl calling convention as default, while CVF used __stdcall, which is required by VB. If you compile using /iface:CVF, you should get the whole CVF routine semantics. (Project/Settings/Fortran/External Procedures/Calling convention) -- Jugoslav www.xeffort.com Please reply to the newsgroup. You can find my real e-mail on my home page above.
From: aeroguy on 10 Dec 2009 11:44 On Dec 10, 1:51 pm, Jugoslav Dujic <jdu...(a)yahoo.com> wrote: > aeroguy wrote: > > On Dec 9, 9:15 pm, user1 <us...(a)example.net> wrote: > >> aeroguy wrote: > > >> [snip] > > >>> I am still experimenting and trying to get at the root of this > >>> problem. > >>> Looking at the code provided, could this be the problem. > >>> Any ideas? > >> End Sub > > > Yes this is working in gfortran. thanks. i will test similar options > > in intel fortran and report back. > > FYI, Intel fortran uses __cdecl calling convention as default, while > CVF used __stdcall, which is required by VB. If you compile using > /iface:CVF, you should get the whole CVF routine semantics. > (Project/Settings/Fortran/External Procedures/Calling convention) > > -- > Jugoslavwww.xeffort.com > Please reply to the newsgroup. > You can find my real e-mail on my home page above.- Hide quoted text - > > - Show quoted text - Thanks for the replies i am working on them. Will report if successful. As a part of my research on solving the fortran dll call from excel problem that i have listed above, i found a good resource that might be useful for anyone who is exploring the magic world of mixed language programming. http://people.sc.fsu.edu/~burkardt/pdf/keinert.pdf This pdf contains general guidelines and a number of examples for linking fortran subroutines to main programs written in c or c++. Hope this helps someone in future :)
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Passing parts of an array to other routine Next: stop adverts on this board? |