http or tcp/ip
allelopath
I see previous discussions like this one:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/04b7fb79c7ccce20/6e57f2e57b631dc2?hl=en#6e57f2e57b631dc2
which indicate the best way is to write it in C and wrap it up for
Fortran.
These discussions, though, are 4 years old. I was wondering if
anything has changed since then.
I need to communicate between Java and Fortran.
My current plan have the Java program execute the fortran program and
have the fortran write to plain text files and use a semaphore.
e p chandler
> which indicate the best way is to write it in C and wrap it up for
> Fortran.
> These discussions, though, are 4 years old. I was wondering if
> anything has changed since then.
>
> I need to communicate between Java and Fortran.
> My current plan have the Java program execute the fortran program and
> have the fortran write to plain text files and use a semaphore.
This may not do exactly what you want but it does show how to
communicate between Java and Fortran.
It uses (IIRC) socket calls to interface Fortran to Java's AWT. So
this is driving a GUI through Java rather than generalized IPC. see
http://www.japi.de
HTH
-- elliot
gary.l...@lmco.com
> which indicate the best way is to write it in C and wrap it up for
> Fortran.
> These discussions, though, are 4 years old. I was wondering if
> anything has changed since then.
>
> I need to communicate between Java and Fortran.
> My current plan have the Java program execute the fortran program and
> have the fortran write to plain text files and use a semaphore.
You can always do it through OS API calls (in any language that can
call the OS API). I believe I recall that David Frank does some FTP
and/or HTTP stuff from Fortran. Maybe he has a publically available
library (likely for CVF or IVF).
David Frank
<gary.l...@lmco.com> wrote in message
news:1174074976.6...@y80g2000hsf.googlegroups.com...
Ok, I have uploaded to my current ISP a pertinent example of what can be
done DIRECTLY using Fortran syntax.
http://home.earthlink.net/~dave_gemini/getfile.f90
and a exe of above....
http://home.earthlink.net/~dave_gemini/getfile.exe
which can read most any file out there..
Beliavsky
<snip>
> Ok, I have uploaded to my current ISP a pertinent example of what can be
> done DIRECTLY using Fortran syntax.
> http://home.earthlink.net/~dave_gemini/getfile.f90
Thanks, David. I am able to compile and run the code with CVF 6.1, but
with an old version of Intel Visual Fortran I get
C:\fortran>ifort XGETFILE.F90 WININET.LIB
Intel(R) Fortran Compiler for 32-bit applications, Version 8.0 Build
20040318Z Package ID: w_fc_pc_8.0.047
XGETFILE.obj : error LNK2019: unresolved external symbol
_InternetOpenUrlA@ referenced in function _MAIN__
XGETFILE.exe : fatal error LNK1120: 1 unresolved externals
If someone wants to modify the code with a currently supported
compiler, it would be nice to have it compile with IVF.
Gary Scott
Thanks, that's very illustrative. I've wanted to create a module of
declarations for wininet for some time (not in CVF for some strange reason).
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Steve Lionel
> C:\fortran>ifort XGETFILE.F90 WININET.LIB
> Intel(R) Fortran Compiler for 32-bit applications, Version 8.0 Build
> 20040318Z Package ID: w_fc_pc_8.0.047
>
> XGETFILE.obj : error LNK2019: unresolved external symbol
> _InternetOpenUrlA@ referenced in function _MAIN__
> XGETFILE.exe : fatal error LNK1120: 1 unresolved externals
>
> If someone wants to modify the code with a currently supported
> compiler, it would be nice to have it compile with IVF.
I can't get to Dave's site to see his code, but if there's a line of
this form:
!DEC$ ATTRIBUTES STDCALL,REFERENCE,ALIAS:"_InternetOpenUrlA@" ::
InternetOpenURL
change it to:
!DEC$ ATTRIBUTES
STDCALL,REFERENCE,DECORATE,ALIAS:"InternetOpenUrlA" :: InternetOpenURL
This should work in both compilers.
ifort 8.0? Really?
Steve
Gary Scott
It actually uses the MS inline [ ] syntax.
>
> ifort 8.0? Really?
>
> Steve
Gary Scott
Result, CVF compiles it. However, fails with cannot get session handle.
Here are the declarations:
INTERFACE ! to 4 WinInet API functions contained in WININET.DLL
INTEGER FUNCTION InternetOpen
[STDCALL,REFERENCE,DECORATE,ALIAS:"InternetOpenA"] &
(sAgent, nAccessType, sProxy, sBypass, nFlags)
INTEGER :: nAccessType, nFlags
CHARACTER(*) :: sAgent[REFERENCE], sProxy[REFERENCE], sBypass[REFERENCE]
END FUNCTION
INTEGER FUNCTION InternetOpenUrl
[STDCALL,REFERENCE,DECORATE,ALIAS:"InternetOpenUrlA"] &
(hInternet,sUrl,sHeaders,nHeadersLength,nFlags,nContext)
INTEGER :: hInternet, nHeadersLength, nFlags, nContext
CHARACTER(*) :: sUrl[REFERENCE], sHeaders[REFERENCE]
END FUNCTION
INTEGER FUNCTION InternetReadFile
[STDCALL,REFERENCE,DECORATE,ALIAS:"InternetReadFile"] &
(hFile, sBuffer, nBytesToRead, nBytesRead)
INTEGER :: hFile, nBytesToRead, nBytesRead[REFERENCE]
CHARACTER(*) :: sBuffer[REFERENCE]
END FUNCTION
INTEGER FUNCTION InternetCloseHandle
[STDCALL,REFERENCE,DECORATE,ALIAS:"InternetCloseHandle"] (hInet)
INTEGER :: hInet
END FUNCTION
INTEGER FUNCTION Nargs() ! returns #args from command line
END FUNCTION
END INTERFACE
Steve Lionel
incorrect assumption. Try this:
INTERFACE ! to 4 WinInet API functions contained in WININET.DLL
INTEGER FUNCTION InternetOpen (sAgent, nAccessType, sProxy, sBypass,
nFlags)
!DEC$ ATTRIBUTES DEFAULT,STDCALL,DECORATE,ALIAS:"InternetOpenA" ::
InternetOpen
INTEGER :: nAccessType, nFlags
CHARACTER(*) :: sAgent, sProxy, sBypass
!DEC$ ATTRIBUTES REFERENCE :: sAgent, sProxy, sBypass
END FUNCTION
INTEGER FUNCTION InternetOpenUrl
(hInternet,sUrl,sHeaders,nHeadersLength,nFlags,nContext)
!DEC$ ATTRIBUTES
DEFAULT,STDCALL,DECORATE,ALIAS:"InternetOpenurlA" :: InternetOpenurl
INTEGER :: hInternet, nHeadersLength, nFlags, nContext
CHARACTER(*) :: sUrl, sHeaders
!DEC$ ATTRIBUTES REFERENCE :: surl, sHeaders
END FUNCTION
INTEGER FUNCTION InternetReadFile (hFile, sBuffer, nBytesToRead,
nBytesRead)
!DEC$ ATTRIBUTES
DEFAULT,STDCALL,DECORATE,ALIAS:"InternetReadFile" :: InternetReadFile
INTEGER :: hFile, nBytesToRead, nBytesRead
!DEC$ ATTRIBUTES REFERENCE :: nBytesRead
CHARACTER(*) :: sBuffer
!DEC$ ATTRIBUTES REFERENCE :: sBuffer
END FUNCTION
INTEGER FUNCTION InternetCloseHandle (hInet)
!DEC$ ATTRIBUTES
DEFAULT,STDCALL,DECORATE,ALIAS:"InternetCloseHandle" ::
InternetCloseHandle
INTEGER :: hInet
END FUNCTION
END INTERFACE
I took out the interface to NARGS - you don't need this in CVF and it
will cause problems in IVF.
Steve
Gary Scott
Modified version posted here: http://www.fortranlib.com/getfileIVF.f90
Sorry about the capitals. Works with the latest CVF and IVF
Gary Scott
Curious, will all of the $DEC instructions go away with an F2k3 compiler
(i.e. does BIND(C) + passby +... cover everything necessary?)
Gary Scott
sheesh, its a Saturday night and here I am...oh well, at least I got a
perfect score on my test.
Gary Scott
Note: This performs a "binary" transfer. For text files, modification
may be needed to translate cr/lf.
Brooks Moses
> Curious, will all of the $DEC instructions go away with an F2k3 compiler
> (i.e. does BIND(C) + passby +... cover everything necessary?)
It seems to me that if there are system-specific things which don't, a
good place for a F2k3 compiler to put them would be as extensions to the
BIND() syntax -- e.g., something like BIND(C, CONVENTION="STDCALL"), or
for that matter BIND(STDCALL), since the "C" of BIND(C) is effectively a
name for a calling convention.
This does mean that the program is no longer standard-conforming, unlike
the !DEC$ attributes which hide in comments on compilers that don't
support them, but I'm not convinced that's a bad thing; in most cases
the program is inherently system-specific anyway, and the directives are
critical to its meaning, so it's likely better to get a clear compiler
error that effectively says "this directive isn't supported".
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
PJH
Brooks Moses wrote
> Gary Scott wrote:
> > Curious, will all of the $DEC instructions go away with an F2k3 compiler
> > (i.e. does BIND(C) + passby +... cover everything necessary?)
>
> It seems to me that if there are system-specific things which don't, a
> good place for a F2k3 compiler to put them would be as extensions to the
> BIND() syntax -- e.g., something like BIND(C, CONVENTION="STDCALL"), or
> for that matter BIND(STDCALL), since the "C" of BIND(C) is effectively a
> name for a calling convention.
On Windows the difference between STDCALL and C is relatively minor (IIRC
just stack cleanup responsibility and "@n" added to the end of the function
name), and I don't think there is any difference at all on other OSs. In
F2003 the name decoration can already be handled by specifying a different
binding label, but I'm not sure if the cleanup responsibility can be
specified. A better solution than identifying different binding types (ie
STDCALL or register) would be to just add any missing binding options. IMO
it is a shame that F2003 decided to call the binding extensions "C
interoperabilty" rather than just "Interoperability". I can't see Fortran
ever defining any other "standard" bindings.
I too would be interested to have a list of binding options not currently
available in F2003. Maybe Steve Lionel is in a good position to comment?
Paul Holden
David Frank
"Steve Lionel" <steve....@intel.com> wrote in message
news:1174179790.6...@n59g2000hsh.googlegroups.com...
> Ugh - the old Microsoft bracket syntax.. Ok, I see I made an
> incorrect assumption. Try this:
Steve, "beauty is in the eye of the beholder"
!DEC$ == !!DOUBLE UGH in my eye..
Steve Lionel
> I too would be interested to have a list of binding options not currently
> available in F2003. Maybe Steve Lionel is in a good position to comment?
Certainly the BIND syntax allows for other options as extensions, but
you'd lose standard-conformance if you used them. BIND(C) along with
VALUE (both already supported by Intel Fortran) go a long way towards
eliminating vendor-specific extensions when interfacing with other
languages and conventions. On IA-32 Windows, STDCALL is still with us
though and would need to be specified in a directive. Note that on
the 64-bit Windows platforms, STDCALL does not exist.
The other extended attribute one needs on Windows is DLLIMPORT/
DLLEXPORT. That will also stay in directives.
The F2003 C interoperability features are very nice, but there's one
part of it which I think was a mistake - that is that character
arguments in a BIND(C) routine are interoperable with a Fortran array
of CHARACTER(1) elements! You can't pass 'ABC' (or even 'ABC'//
CHAR(0)) to such an argument and be standard-conforming. I am sure
this was done with good intentions, but I also think it will cause
grief for users. We're intending to allow this combination as an
extension.
Steve
Gary Scott
A fairly complete set of declarations for wininet (the windows internet
access API) is stored here: http://www.fortranlib.com/Wininet.zip
I am not completely certain where I got these (perhaps John Termine). I
checked for copyrights and it indicates no restriction/free to use. If
someone knows otherwise, please let me know. It is possible that this
is for CVF (circa 2003) (haven't tried to compiler with IVF yet).
Strangely, I still don't see this DLL support in IVF, but perhaps it's
hidden somewhere that I haven't found.
Looking through some of the source files for windows API declarations, I
have to say that some of the newer one's written by Steve are MUCH
better structured/commented.
Brooks Moses
> On Windows the difference between STDCALL and C is relatively minor (IIRC
> just stack cleanup responsibility and "@n" added to the end of the function
> name), and I don't think there is any difference at all on other OSs. In
> F2003 the name decoration can already be handled by specifying a different
> binding label, but I'm not sure if the cleanup responsibility can be
> specified. A better solution than identifying different binding types (ie
> STDCALL or register) would be to just add any missing binding options. IMO
> it is a shame that F2003 decided to call the binding extensions "C
> interoperabilty" rather than just "Interoperability". I can't see Fortran
> ever defining any other "standard" bindings.
Arguably, it might make sense to define a standard binding to C++ for
the object-oriented stuff, given that there is a C++ standard ABI. I
don't know how resolvable the clashes caused by different philosophies
of object-orientation would be, though.
Gary Scott
> Brooks Moses wrote
>
>>Gary Scott wrote:
>>
>>>Curious, will all of the $DEC instructions go away with an F2k3 compiler
>>>(i.e. does BIND(C) + passby +... cover everything necessary?)
>>
>>It seems to me that if there are system-specific things which don't, a
>>good place for a F2k3 compiler to put them would be as extensions to the
>>BIND() syntax -- e.g., something like BIND(C, CONVENTION="STDCALL"), or
>>for that matter BIND(STDCALL), since the "C" of BIND(C) is effectively a
>>name for a calling convention.
>
>
> On Windows the difference between STDCALL and C is relatively minor (IIRC
> just stack cleanup responsibility and "@n" added to the end of the function
> name), and I don't think there is any difference at all on other OSs. In
> F2003 the name decoration can already be handled by specifying a different
> binding label, but I'm not sure if the cleanup responsibility can be
> specified. A better solution than identifying different binding types (ie
> STDCALL or register) would be to just add any missing binding options. IMO
> it is a shame that F2003 decided to call the binding extensions "C
> interoperabilty" rather than just "Interoperability". I can't see Fortran
> ever defining any other "standard" bindings.
I personally don't think I want "standard" bindings. I want to be able
to specify the low level details in a standard way. What I want to do
is to be able to use Fortran to produce libraries compatible with the
assumptions made by other languages.
>
> I too would be interested to have a list of binding options not currently
> available in F2003. Maybe Steve Lionel is in a good position to comment?
>
> Paul Holden
>
>
Richard Maine
> ..I think was a mistake - that is that character
> arguments in a BIND(C) routine are interoperable with a Fortran array
> of CHARACTER(1) elements! You can't pass 'ABC' (or even 'ABC'//
> CHAR(0)) to such an argument and be standard-conforming.
Yes, you can. I distinctly recall going to a lot of trouble to make sure
this worked. See Notes 15.29 and 15.23 for a (bried) explanation and
example of exactly this. I knoew this was an mportant issue; that's why
I wrote (the first draft of) Note 15.23.
See also pg 170, lines 25:26. The mention of the C character kind there
is specifically to guarantee that this will work even if the C character
kind doesn't happen to be the default kind. That was a special rule for
default character, but it was extended to also apply to the C character
kind. In essence, the rule amounts to a requirement that characters of
length greater than 1 be represented the same way as an array. It is
possible for there to be character kinds that aren't represented that
way (not that I know of any actual examples in existance).
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Toon Moene
> Arguably, it might make sense to define a standard binding to C++ for
> the object-oriented stuff, given that there is a C++ standard ABI. I
> don't know how resolvable the clashes caused by different philosophies
> of object-orientation would be, though.
Mark Mitchell, the current GCC release manager, told me at the 2003 GCC
Summit, that he was thinking of such a binding. At that time, gfortran
was just beginning to generate useful, runnable, code.
--
Toon Moene - e-mail: to...@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Who's working on GNU Fortran:
http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
Brooks Moses
> Brooks Moses wrote:
>> Arguably, it might make sense to define a standard binding to C++ for
>> the object-oriented stuff, given that there is a C++ standard ABI. I
>> don't know how resolvable the clashes caused by different philosophies
>> of object-orientation would be, though.
>
> Mark Mitchell, the current GCC release manager, told me at the 2003 GCC
> Summit, that he was thinking of such a binding. At that time, gfortran
> was just beginning to generate useful, runnable, code.
Yes, I got the idea from him as well.
Jan Vorbrüggen
> length greater than 1 be represented the same way as an array. It is
> possible for there to be character kinds that aren't represented that
> way (not that I know of any actual examples in existance).
Isn't UTF-8 an example of such a case? My understanding is you actually have
to parse the byte stream in order to delineate character boundaries.
Jan
Jan Vorbrüggen
> good place for a F2k3 compiler to put them would be as extensions to the
> BIND() syntax -- e.g., something like BIND(C, CONVENTION="STDCALL"), or
> for that matter BIND(STDCALL), since the "C" of BIND(C) is effectively a
> name for a calling convention.
My understanding of the intent of BIND(C) was that there are pairs of
compilers - i.e., a Fortran and a C compiler - that implement a common,
interoperable ABI, and that BIND(C) referred to this common ABI.
For the different Win32 ABIs, I could imagine that a compiler switch would
tranparently and in a standard-conforming way select which of the several ABIs
should be realized by a BIND(C). The comment-like directives would just
allow finer control where program units with different ABI requirements were
put together into one source file, but not add any new capability. This might
even be possible for the DLLEXPORT and DLLIMPORT "ABIs".
Jan
Jan Vorbrüggen
> the object-oriented stuff, given that there is a C++ standard ABI.
There is!? That's news to me. I distinctly remember a recommendation (by
Stroustrup?) that different C++ compilers should use incompatible name
mangling, because behind the scenes the details of their ABI would be
incompatible, and you'd rather find out earlier than later.
Jan
Jan Vorbrüggen
> !DEC$ == !!DOUBLE UGH in my eye..
The !DEC$ syntax has one overiding advantage: it is standard-conforming
Fortran source code, while the MS alternative is not.
Jan
Dan Nagle
The UTF-* character sets are, IIRC, all constant-size.
Where you get into "interesting" situations are with some
of the Japanese character sets, which are either 8-bit or 16-bit,
depending on the value. That is, values 0-127 are eight bit,
so the next byte is the next character, but
if the high bit is set the value is 16-bit, so read the next byte
as a part of this character.
Note that these character sets cannot be implemented
in Fortran in a standard-conforming way.
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
glen herrmannsfeldt
(snip)
> The UTF-* character sets are, IIRC, all constant-size.
UTF-8 is the variable size representation for unicode.
http://en.wikipedia.org/wiki/UTF-8
The first 128 are single byte characters for ASCII-7,
past that there are two, three, and four byte codes.
> Where you get into "interesting" situations are with some
> of the Japanese character sets, which are either 8-bit or 16-bit,
> depending on the value. That is, values 0-127 are eight bit,
> so the next byte is the next character, but
> if the high bit is set the value is 16-bit, so read the next byte
> as a part of this character.
> Note that these character sets cannot be implemented
> in Fortran in a standard-conforming way.
-- glen
Gary Scott
But that's really NOT what users wanted. What was wanted was the
ability to specify those low level details so that we could interface
with any language and not have to wait on the committe to add a
bind(ada), bind(jovial), bind(smalltalk)...
>
> Jan
Jan Vorbrüggen
> ability to specify those low level details so that we could interface
> with any language and not have to wait on the committe to add a
> bind(ada), bind(jovial), bind(smalltalk)...
There's nothing in the standard, I'm sure, that says the companion compiler
must compile C 8-).
If you follow my vision of the compiler with the ABI switch, all BIND(C) says
is "use a potentially different ABI for this routine interface", and the
compiler switch specifies what that ABI should be.
Jan
Pierre Asselin
> The UTF-* character sets are, IIRC, all constant-size.
You have to distinguish between character sets and encodings.
The character set (for example Unicode) assigns numerical values
to characters; the encoding (for exmple UTF-8) specifies how
to represent the values in memory or over the wire.
> Where you get into "interesting" situations are with some
> of the Japanese character sets, which are either 8-bit or 16-bit,
> depending on the value. That is, values 0-127 are eight bit,
> so the next byte is the next character, but
> if the high bit is set the value is 16-bit, so read the next byte
> as a part of this character.
That sounds like an encoding.
--
pa at panix dot com
gary.l...@lmco.com
Is encoding the same thing as "code page"?
Steve Lionel
wrote:
> If you follow my vision of the compiler with the ABI switch, all BIND(C) says
> is "use a potentially different ABI for this routine interface", and the
> compiler switch specifies what that ABI should be.
Using a switch for this means that your application can use one and
only one ABI. In the IA-32 Windows world, which appears to have
prompted discussion of STDCALL and DLLIMPORT, it is quite common to
use a mixture of ABIs in a Fortran application. I would be hesitant
about overloading the name C for this purpose, and my guess is that
the whole reason that the keyword C is used in BIND is to allow for
other possible keywords to appear here for other ABIs.
The whole point of standard syntax is to be portable - at least among
implementations which support the particular feature you want. We
have a defacto standard in the !DEC$ ATTRIBUTES syntax, for good or
for bad - most of the Windows compilers I have seen support it. I
could imagine extending BIND to encompass the various things one wants
to do, but it's not clear to me that it adds a lot of value in
general to do so as these would just be extensions spelled another
way.
Steve
Jan Vorbrüggen
> only one ABI.
No, you now have two: One for interfaces without the BIND(C) attribute (if it
is an attribute), and those with BIND(C). Both can be present simultaneously
in a single source file in a standard-conforming way. The compiler gets to
define what those two ABIs actually are at compile time, and that decision
could be driven by switches.
> In the IA-32 Windows world, which appears to have
> prompted discussion of STDCALL and DLLIMPORT, it is quite common to
> use a mixture of ABIs in a Fortran application.
Exactly.
Jan
Dick Hendrickson
> > But that's really NOT what users wanted. What was wanted was the
>> ability to specify those low level details so that we could interface
>> with any language and not have to wait on the committe to add a
>> bind(ada), bind(jovial), bind(smalltalk)...
>
> There's nothing in the standard, I'm sure, that says the companion
> compiler must compile C 8-).
Correct, there's even words that say it doesn't have to be C. It
can even be its own companion! (There's even a note that says that.)
But, it does have to different right things depending on whether or
not it sees things like a VALUE attribute or an argument.
Dick Hendrickson
gary.l...@lmco.com
wrote:
> Jan Vorbrüggen wrote:
> > > But that's really NOT what users wanted. What was wanted was the
> >> ability to specify those low level details so that we could interface
> >> with any language and not have to wait on the committe to add a
> >> bind(ada), bind(jovial), bind(smalltalk)...
>
> > There's nothing in the standard, I'm sure, that says the companion
> > compiler must compile C 8-).
>
> Correct, there's even words that say it doesn't have to be C. It
> can even be its own companion! (There's even a note that says that.)
> But, it does have to different right things depending on whether or
> not it sees things like a VALUE attribute or an argument.
>
> Dick Hendrickson
However, it is insufficient. We need to be able to specify things
like where stack cleanup is to occur. I don't just want to work with
a companion processor, I want to be able to produce code that works
with a processor that I may not have but that I know its argument
passing convention.
Dick Hendrickson
> On Mar 23, 11:00 am, Dick Hendrickson <dick.hendrick...@att.net>
> wrote:
>> Jan Vorbrüggen wrote:
>>> > But that's really NOT what users wanted. What was wanted was the
>>>> ability to specify those low level details so that we could interface
>>>> with any language and not have to wait on the committe to add a
>>>> bind(ada), bind(jovial), bind(smalltalk)...
>>> There's nothing in the standard, I'm sure, that says the companion
>>> compiler must compile C 8-).
>> Correct, there's even words that say it doesn't have to be C. It
>> can even be its own companion! (There's even a note that says that.)
>> But, it does have to different right things depending on whether or
>> not it sees things like a VALUE attribute or an argument.
>>
>> Dick Hendrickson
>
> However, it is insufficient. We need to be able to specify things
> like where stack cleanup is to occur. I don't just want to work with
> a companion processor, I want to be able to produce code that works
> with a processor that I may not have but that I know its argument
> passing convention.
>
>
with standard language to define things like "stack cleanup for a
companion that we don't know anything about"? The standard doesn't
even require a stack, let alone try to define its options.
The current scheme requires the compiler to have a bit more than
zero companion processors and allows it to have many. You can
pick the one you want and then the compiler must then do the selected
right thing. All you have to do is be able to describe the interface
in a combination of Fortran and C based characteristics. I don't
see how the standard could be any more specific. For good or bad
(bad IMO), C has become the default standard for how things interlink.
True, spelling the attribute "BIND(C)" seems to imply that
BIND(whatever) is a possibility. But, BIND(C) has so many C specific
things spread throughout the standard that I, personally, doubt that
there will ever be another language binding.
Dick Hendrickson
Richard Maine
> However, it is insufficient. We need to be able to specify things
> like where stack cleanup is to occur. I don't just want to work with
> a companion processor, I want to be able to produce code that works
> with a processor that I may not have but that I know its argument
> passing convention.
You just aren't likely to ever (well, forseeably) be able to do that in
a standard way. That's too much into non-portable implementation
details. I understand needing to be able to do such things. But that's
just not something the standard is going to be of much help in. Try to
push it if you want (not that you need my permission), but I think it
would be wasted effort. The cost/benefit of putting things like that
into the standard doesn't seem even close to there. The costs are very
large - even to specify such things in appropriate standard-speak; and
the fraction of people who it would benefit seems small. Yes, I
understand that you would be one of those people and that there are also
others, but it doesn't seem like a very large set.
gary.l...@lmco.com
wrote:
I just don't believe that it would be that difficult to come up with a
99% solution, i.e. one that works in 100% of current implementations
and 99% of unanticipated future implementations. Those can be
addressed when the time comes. As for stack cleanup, it could
possibly be specified as just "callee cleanup" or "caller cleanup" or
"preclean" or "postclean" or something even more generic. If possible
to specify the gory details of what cleanup actually means in a
consistent way (if it is commonly done certain ways), I'd say that
ability to specify current practice should be sufficient. Exceptions
can be addressed by future standard revisions (likely extremely minor
ones). I don't want to have to put compiler unique directives in the
code in order to produce targeted API libraries.
glen herrmannsfeldt
> <gary.l...@lmco.com> wrote:
>>However, it is insufficient. We need to be able to specify things
>>like where stack cleanup is to occur. I don't just want to work with
>>a companion processor, I want to be able to produce code that works
>>with a processor that I may not have but that I know its argument
>>passing convention.
> You just aren't likely to ever (well, forseeably) be able to do that in
> a standard way. That's too much into non-portable implementation
> details. I understand needing to be able to do such things. But that's
> just not something the standard is going to be of much help in.
I agree, there are just too many possibilities.
I recently downloaded g95 for the AMD x86-64 processor. There are
two versions of each binary release, one with 32 bit INTEGER, and
one with 64 bit INTEGER. Those will obviously have an incompatible
calling sequence for INTEGER variables.
It would be nice to specify the way to indicate differences,
though. Should it be a different BIND parameter, or a
subparameter to BIND? BIND(C,STDCALL), BIND(C(STDCALL)),
BIND(C,INTEGER(64)), BIND(C,POINTER(64),INTEGER(32))
I suppose one should also be able to specify alternate Fortran
calling sequences, possibly caller or callee pops the stack,
and the size of pointers. That is a separate question from
BIND(C).
-- glen
gary.l...@lmco.com
> <gary.l.sc...@lmco.com> wrote:
> > However, it is insufficient. We need to be able to specify things
> > like where stack cleanup is to occur. I don't just want to work with
> > a companion processor, I want to be able to produce code that works
> > with a processor that I may not have but that I know its argument
> > passing convention.
>
> You just aren't likely to ever (well, forseeably) be able to do that in
> a standard way. That's too much into non-portable implementation
> details. I understand needing to be able to do such things. But that's
> just not something the standard is going to be of much help in. Try to
> push it if you want (not that you need my permission), but I think it
> would be wasted effort. The cost/benefit of putting things like that
> into the standard doesn't seem even close to there. The costs are very
> large - even to specify such things in appropriate standard-speak; and
> the fraction of people who it would benefit seems small. Yes, I
> understand that you would be one of those people and that there are also
> others, but it doesn't seem like a very large set.
This I especially don't understand. The vast majority of software
being written today involves OS API interfacing. In the interest of
improving Fortran's suitability for this purpose, it seems super-well
worth the effort to me.
Richard Maine
> On Mar 23, 1:04 pm, nos...@see.signature (Richard Maine) wrote:
> > <gary.l.sc...@lmco.com> wrote:
> > > However, it is insufficient. We need to be able to specify things
> > > like where stack cleanup is to occur...
> > You just aren't likely to ever (well, forseeably) be able to do that in
> > a standard way. That's too much into non-portable implementation
> > details.
>
> This I especially don't understand. The vast majority of software
> being written today involves OS API interfacing.
And the vast amount of OPI interfacing doesn't require anything even
vaguely like that. I've done quite a lot of OS API interfacing myself,
and I know that plenty of other people also do. Yes, I considert that a
big deal, but it almost never needs that level of implementation
control. Perhaps what you are doing does; I can well believe that. But
what most people do doesn't. I almost never see requests for anything
like this. I'd say you are the source of the large majority of the
requests for it I've seen. That doesn't mean your request isn't valid,
but that's not enough to make it happen. Not within multiple orders of
magnitude of enough.
I can tell that you have little idea of how much work it would be to put
material like that in the standard. It would be quite a lot. Protests
about how simply it can be done won't fly. I've seen plenty of those
kinds of claims.
Anyway, whether you understand it or not, I am confident that the market
isn't there. I'm actually trying to help you, in a backwards sort of
way, by arguing against this. What I'm trying to help you do is not
waste your time. (Boy, I almost screwed up there. Left the "not" out of
that sentence at first, which really would have sounded bad.) Because
I'm quite sure that any time you put into pushing this will be wasted. I
know that I've put about all the time I feel like into trying to explain
that, even if I haven't done a good job.
Lane Straatman
<gary.l...@lmco.com> wrote in message
news:1174678941.8...@l77g2000hsb.googlegroups.com...
> On Mar 23, 1:04 pm, nos...@see.signature (Richard Maine) wrote:
>> <gary.l.sc...@lmco.com> wrote:
>> > However, it is insufficient. We need to be able to specify things
>> > like where stack cleanup is to occur. I don't just want to work with
>> > a companion processor, I want to be able to produce code that works
>> > with a processor that I may not have but that I know its argument
>> > passing convention.
>>
>> You just aren't likely to ever (well, forseeably) be able to do that in
>> a standard way. That's too much into non-portable implementation
>> details. I understand needing to be able to do such things. But that's
>> just not something the standard is going to be of much help in. Try to
>> push it if you want (not that you need my permission), but I think it
>> would be wasted effort. The cost/benefit of putting things like that
>> into the standard doesn't seem even close to there. The costs are very
>> large - even to specify such things in appropriate standard-speak; and
>> the fraction of people who it would benefit seems small. Yes, I
>> understand that you would be one of those people and that there are also
>> others, but it doesn't seem like a very large set.
>
> This I especially don't understand. The vast majority of software
> being written today involves OS API interfacing. In the interest of
> improving Fortran's suitability for this purpose, it seems super-well
> worth the effort to me.
standard, and I think his above opinion is case in point. I sometimes ask
myself what I would do if 51% of the committee were under my influence.
Does windows API live in standard fortran anywhere? I read a lot of posts
that talk of "bindings," and I'm underequipped to understand them.
--
LS
Gary Scott
> <gary.l...@lmco.com> wrote:
>
>
>>On Mar 23, 1:04 pm, nos...@see.signature (Richard Maine) wrote:
>>
>>><gary.l.sc...@lmco.com> wrote:
>>>
>>>>However, it is insufficient. We need to be able to specify things
>>>>like where stack cleanup is to occur...
>
>
>>>You just aren't likely to ever (well, forseeably) be able to do that in
>>>a standard way. That's too much into non-portable implementation
>>>details.
>>
>>This I especially don't understand. The vast majority of software
>>being written today involves OS API interfacing.
>
>
> And the vast amount of OPI interfacing doesn't require anything even
> vaguely like that. I've done quite a lot of OS API interfacing myself,
> and I know that plenty of other people also do. Yes, I considert that a
> big deal, but it almost never needs that level of implementation
> control. Perhaps what you are doing does; I can well believe that. But
> what most people do doesn't. I almost never see requests for anything
> like this. I'd say you are the source of the large majority of the
> requests for it I've seen. That doesn't mean your request isn't valid,
> but that's not enough to make it happen. Not within multiple orders of
> magnitude of enough.
>
> I can tell that you have little idea of how much work it would be to put
> material like that in the standard.
I've managed teams of 50 in efforts to write and test (integrate major
software/system capability changes into) specifications consisting of
50000 pages of prose (including interface specifications). Actually,
that was just one project, I had up to 22 simultaneously in-progress
projects at one point (sheesh). I'm well aware of the challenges and
costs (and also that this is a volunteer effort). And these were
mission critical/aircraft can crash or drop things where it shouldn't
specifications.
It would be quite a lot. Protests
> about how simply it can be done won't fly. I've seen plenty of those
> kinds of claims.
>
> Anyway, whether you understand it or not, I am confident that the market
> isn't there. I'm actually trying to help you, in a backwards sort of
> way, by arguing against this. What I'm trying to help you do is not
> waste your time. (Boy, I almost screwed up there. Left the "not" out of
> that sentence at first, which really would have sounded bad.) Because
> I'm quite sure that any time you put into pushing this will be wasted. I
> know that I've put about all the time I feel like into trying to explain
> that, even if I haven't done a good job.
>
I hadn't planned on pushing it. I have little free time to spend on it.
But I stand by my statement that you can fairly easily survey all
current compilers and derive a pretty darn complete list of needed
directives.
Brooks Moses
I remembered hearing that there was, but a bit of poking around with
Google indicates that I'm mistaken. :(
I suspect what I'm remembering is this, which is Itanium-specific
(although notes that it's written in such a way as to be usable on other
architectures):
http://www.codesourcery.com/cxx-abi/
Pierre Asselin
> On Mar 23, 8:57 am, p...@see.signature.invalid (Pierre Asselin) wrote:
> >
> > You have to distinguish between character sets and encodings.
> > The character set (for example Unicode) assigns numerical values
> > to characters; the encoding (for exmple UTF-8) specifies how
> > to represent the values in memory or over the wire.
> Is encoding the same thing as "code page"?
Not sure. I think "code page" is an IBM-ism that predates the
charset/encoding distinction. I think a code page is both.
Googling a bit, I see that my terminology is simplistic. My
"encoding" is actually a "character encoding form" (or is it a
character encoding scheme ? ah, it depends). In my defense, Fortran
2003 uses the same terms as I do, for example 4.4.4, 9.4.5.7 .
See http://www.unicode.org/glossary/ for the official terminology.
And you thought the Fortran standards were hard to parse ?
Fortran question to the vendors: if your selected_char_kind('ISO_10646')
is nonnegative, how do you implement the comparison operators ? :P
Jan Vorbrüggen
> But I stand by my statement that you can fairly easily survey all
> current compilers and derive a pretty darn complete list of needed
> directives.
No way José! With gfortran, a Fortran 90 compiler now runs on almost any
computer platform in existance, and you have no idea how many strange ABIs all
of those have. Or perhaps you do? Avionics is a lot of embedded software on
running on strange pieces of hardware.
But I'd argue similarly with Richard that you don't really need that. Even
Winwoes "only" has three different ABIs (if I'm not mistaken). Specifying at a
suitable level (see my replies to Steve L.) the ABI to the compiler and using
the BIND(C) features to specify calling mechanisms and data types should be
enough to do everything you want. Even the required bit/byte packing etc. for
descriptors should be doable this way.
Jan
Jan Vorbrüggen
> that talk of "bindings," and I'm underequipped to understand them.
No, it doesn't. And which API, by the way? Win32, which is what most people
see? Or the actual syscall API, which is quite different?
"Binding" is really a way of giving you access, within a certain "language" of
specifying things (e.g., a Fortran77-compliant CALL statement), to things that
cannot canonically be specified in that particular language. For instance, if
wanted access to some POSIX functions that were originally defined with C in
mind and therefore had a trivial C "binding" from Fortran77, things like call
by value and lenght (and capitalization!) of names got in your way. The
binding specifies the interface of a translator, if you will, from one way of
specifying the interface to the other one. Whether there is any actual code
involved in this translator depends on the details and on the implementation.
The whole point of BIND(C) is to achieve sufficient flexibility that you can
do away with the need for specialized bindings and to give you the ability to
write them yourself directly in the language of your choice, i.e., Fortran 2003.
Jan
Jan Vorbrüggen
> is nonnegative, how do you implement the comparison operators ? :P
_Very_ carefully 8-), and you need to ask the user for the collating sequence
he wants to employ. Or don't you?
I18N is a mess. Including finding out _why_ it is abbreviated I18N (before
wikipedia and google).
Jan