F2000 BIND attribute
Jugoslav Dujic
specification. However, it is unclear to me whether
a language other than C may be specified in BIND attribute/statement?
I understand that currently only C bindings are standardized,
but how bindings to other languages are treated?
I.e. would hypothetical:
SUBROUTINE Foo, BIND(PASCAL, NAME="_Foo@0")
be standard-conforming or treated as an extension? Should compilers
which don't implement that binding issue an error or simply
ignore the attribute with a possible warning? (I know that the last
sentence is a processor-implementation issue which the Standard does not know
about -- I just wanted to express the question in more common terms).
In any case, I feel that some more precise wording about the issue is
needed.
The main reason that I ask is binding with Windows API; the default
calling convention there is __stdcall (which AFAIK originated from
early pascal compilers and is also known as Pascal).
Standard does not address calling conventions, which are an important
issue in mixed-language programming. I don't expect such processor-
dependent topic to be in the Standard, but I feel it can be conveniently
abstracted behind BIND() attribute. On Unixen, to my best knowledge,
the prevailing calling convention is __cdecl, but on Windoze at least
two ("semi-standard") are there, along with a lot of vendor-specific
ones (usually utilizing registers to pass first couple of arguments).
I expect (finally) to be able to write standard-conforming and portable
Windows applications.
--
Jugoslav
___________
www.geocities.com/jdujic
Arjen Markus
>
> Leafing through 007.pdf I paid some attention to BIND(C)
> specification. However, it is unclear to me whether
> a language other than C may be specified in BIND attribute/statement?
> I understand that currently only C bindings are standardized,
> but how bindings to other languages are treated?
> On Unixen, to my best knowledge,
> the prevailing calling convention is __cdecl, but on Windoze at least
> two ("semi-standard") are there, along with a lot of vendor-specific
> ones (usually utilizing registers to pass first couple of arguments).
> I expect (finally) to be able to write standard-conforming and portable
> Windows applications.
(I have always regarded the Windows platform to be the one
giving all the extra complications, like __stdcall and internal
names that can not be constructed in C etc :-)
But concerning the last point: I am a happy user of the "cfortran.h"
utility nowadays which takes care of most if not all interfacing
problems in a highly portable way! You can find it at:
<http://www-zeus.desy.de/~burow>
Regards,
Arjen
Dan Nagle
My understanding from listening to the interoperability
subgroup is that any language may be called via bind( c),
_if_ you can express the entry point to be called as a C
prototype. Note that this means that you may have to tell
the other compiler that you want to be called from C!
Different calling conventions amount to different coprocessors.
There was at one time a bindname= "backdoor" to allow
the programmer to specify the external name exactly as seen
by the loader. However, this was removed on the grounds that
if the compiler can't get the name right, the chances of getting
the rest of the calling convention right would be nil.
HTH
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
Jugoslav Dujic
news:3D2C14A4...@wldelft.nl...
| Jugoslav Dujic wrote:
| >
| > Leafing through 007.pdf I paid some attention to BIND(C)
| > specification. However, it is unclear to me whether
| > a language other than C may be specified in BIND attribute/statement?
| > I understand that currently only C bindings are standardized,
| > but how bindings to other languages are treated?
|
| > On Unixen, to my best knowledge,
| > the prevailing calling convention is __cdecl, but on Windoze at least
| > two ("semi-standard") are there, along with a lot of vendor-specific
| > ones (usually utilizing registers to pass first couple of arguments).
| > I expect (finally) to be able to write standard-conforming and portable
| > Windows applications.
|
| (I have always regarded the Windows platform to be the one
| giving all the extra complications, like __stdcall and internal
| names that can not be constructed in C etc :-)
I'm not a fan of Windows either, to be sure, but I earn my bread
there... (and, btw, the only other NG where I actively participate is
comp.os.ms-windows.programmer.win32).
| But concerning the last point: I am a happy user of the "cfortran.h"
| utility nowadays which takes care of most if not all interfacing
| problems in a highly portable way! You can find it at:
| <http://www-zeus.desy.de/~burow>
Yes, I'm aware of cfortran.h, but IMHO it solves problems only on C end
of the rope. My interfacing with C is only on dll level; I call C or
API functions frequently. What I want is to be able to write portable
Windows programs, e.g. something like
INTEGER FUNCTION WinMain(hInst,hPrevInst,szCmdLine,nCmdShow), &
BIND(WINAPI, NAME="WinMain")
USE ISO_C_BINDING
USE STANDARD_WINAPI_BINDING !I made this one up
USE MY_MODULE
!VALUE is probably redundant with BIND() here?
INTEGER, VALUE, INTENT(IN):: hInst, hPrevInst, nCmdShow
CHARACTER(LEN=1), VALUE:: szCmdLine
INCLUDE "Resource.fd"
INTERFACE
INTEGER FUNCTION DialogBox(hInst,iTemplate,hWnd,lpDialogFunc), &
BIND(WINAPI, NAME="DialogBoxA")
INTEGER, VALUE, INTENT(IN):: hInst, hWnd, lpDialogFunc
INTEGER(C_INT), INTENT(IN):: lpDialogFunc
END FUNCTION
END INTERFACE
WinMain = DialogBox(hInst, IDD_MYDIALOG, 0, C_LOC(MyDialogFunc))
END FUNCTION WinMain
!=========
MODULE MY_MODULE
CONTAINS
INTEGER FUNCTION MyDialogFunc(hWnd, Msg, wParam, lParam), BIND(WINAPI)
...
I'm not (normally :-)) versatile enough in F2000 to be sure all of the
above is valid syntax; I just wanted to illustrate. Such (now
hypothetic) program will be portable across all Windows F2K compilers;
of course, on, say, Unixen it doesn't make sense. What I feel is missing
from F2K draft is thing like BIND(WINAPI) (or whatever you call it).
I don't say it should be defined there, just that a door should be open
for Win32 vendors to gather and write an auxiliary standard one day
(containing BIND(WINAPI) and STANDARD_WINAPI_BINDING).
--
Jugoslav
___________
www.geocities.com/jdujic
GerryThomas
MainWin for VS .NET. COM runs on Compaq TrueUnix (might have the name
wrong so apologies Steve). VisualMain recompiles Windows source code
(API and all) to create native Unix applications. Its expensive
though. Also, Iona have done a lot on getting COM and Corba objects to
coexist and interoperate in a Windows/Unix arena.
Ciao,
Gerry T.
"Jugoslav Dujic" <jdujic...@uns.ns.ac.yu> wrote in message
news:agh8f0$l5m2q$1...@ID-106075.news.dfncis.de...
Jugoslav Dujic
news:6g9oiu4oo7jv3ohnr...@4ax.com...
| Hello,
|
| My understanding from listening to the interoperability
| subgroup is that any language may be called via bind( c),
| _if_ you can express the entry point to be called as a C
| prototype. Note that this means that you may have to tell
| the other compiler that you want to be called from C!
But my point is -- there's no "other compiler" in the case
in question (i.e. it is located in Redmond and not quite accessible
to me :-)). The prototype of ("my") first entry-point is predefined
by API as
int __stdcall WinMain(int, int, char*, int)
there is a zillion of APIs, as well as callbacks defined by "me",
and 99% of them are __stdcall. But everything is buried in system
libraries and given to "me" as-is.
| Different calling conventions amount to different coprocessors.
|
| There was at one time a bindname= "backdoor" to allow
| the programmer to specify the external name exactly as seen
| by the loader. However, this was removed on the grounds that
| if the compiler can't get the name right, the chances of getting
| the rest of the calling convention right would be nil.
I agree with that reasoning. I should have omit linker decoration
from my sample.
--
Jugoslav
___________
www.geocities.com/jdujic
Arjen Markus
>
I think I am beginning to understand what you imply. But just
beginning. I have not dealt with cfortran.h in precisely that
manner. It would be interesting, though.
Regards,
Arjen
Dan Nagle
Then you will have, probably on the compiler command line,
to specify "Windows stdcall protocol". This is, of course,
documented by the compiler vendor and not specified by the
standard.
This may imply that the compiler has, hidden away somewhere,
more than one iso_c_binding module. To make sure you get
the one you want, you should specify
use, intrinsic: iso_c_binding
in addition to the compiler command line switch. (Now that
we have intrinsic modules, let us enjoy them.)
Similar to intrinsic procedures, you _can_ override the intrinsic
with your own. YMMV
HTH
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
On Wed, 10 Jul 2002 14:55:36 +0200, "Jugoslav Dujic"
<jdujic...@uns.ns.ac.yu> wrote:
>"Dan Nagle" <dna...@erols.com> wrote in message
>news:6g9oiu4oo7jv3ohnr...@4ax.com...
>| Hello,
>|
>| My understanding from listening to the interoperability
>| subgroup is that any language may be called via bind( c),
>| _if_ you can express the entry point to be called as a C
>| prototype. Note that this means that you may have to tell
>| the other compiler that you want to be called from C!
>
>But my point is -- there's no "other compiler" in the case
>in question (i.e. it is located in Redmond and not quite accessible
>to me :-)). The prototype of ("my") first entry-point is predefined
>by API as
>
>int __stdcall WinMain(int, int, char*, int)
>
>there is a zillion of APIs, as well as callbacks defined by "me",
>and 99% of them are __stdcall. But everything is buried in system
>libraries and given to "me" as-is.
>
<snip>
Richard Maine
> SUBROUTINE Foo, BIND(PASCAL, NAME="_Foo@0")
>
> be standard-conforming or treated as an extension?
That would be an extension. Mind you, it is an extension that
the standard all but "invites", but it would still be an extension.
It is plausible that the standard might even adopt some such extensions
as a part of some future standard or perhaps an optional add-on
to the standard.
> The main reason that I ask is binding with Windows API; the default
> calling convention there is __stdcall (which AFAIK originated from
> early pascal compilers and is also known as Pascal).
Yes, the issue of multiple calling conventions came up *A LOT*
during work on these features. I think there was at least one case
other than on Windows - the Cray folk were very interested in this
subject, for example.
I believe that the expectation is that, if the Fortran compiler
supported multiple C calling conventions, that would be a compiler
switch. An extension like the above would also be plausible,
particularly if you wanted to support two different calling conventions
in the same program. (By the time you are doing that, you are
pretty much bound to have some system-dependence anyway).
As Dan mentioned, there was once a bindname specifier...which I found
*VERY* confusing - people kept explaining it to me orally, but those
explanations never actually made their way into the standard in a
comprensible way.
--
Richard Maine | Good judgment comes from experience;
email: my last name at host.domain | experience comes from bad judgment.
host: altair, domain: dfrc.nasa.gov | -- Mark Twain