Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.23/text0019.txt

Text File | 1991-06-15 | 9.5 KB | 262 lines

Submitted-by: [e-mail] (Peter Collinson)

[ The sources to this, and the next two messages, are available on
uunet.uu.net, in ~ftp/comp.std.unix/Updates/{9,17,b11}.mm.  I will make
further updates available there as I get them. -- mod ]

An Update on UNIX-Related Standards Activities

1003.9: FORTRAN Bindings
March 26, 1991


Joseph J. King, Ph.D. <[e-mail]> reports on the January 7-11, 1991
meeting in New Orleans, LA:

POSIX is a set of portability standards that will span a diverse set of
architectures such as VMS, UNIX, and OS/2.  The FORTRAN binding to POSIX
system services is nearing approval.  Here I'll discuss the current
state, including the relationship of language-independent POSIX
standards to the FORTRAN language binding, and the possibility that the
POSIX/FORTRAN binding will be rejected by the International Standards
Organization (ISO).

Portable Operating System Interface: POSIX

A POSIX standard is one of a group of standards being developed by the
Institute of Electric and Electronic Engineers (IEEE), in cooperation
with the International Standards Organization (ISO).  The primary
mission of these standards is to define a portable user and application
environment.  The POSIX development effort is currently subdivided into
19 separate, numbered efforts - 1003.0 (POSIX Guide) through 1003.18
(PEP).  Taken together, these groups are forming operating-system
standards in the areas that range from networking to real-time.  Half a
dozen additional groups, also supervised by the IEEE's Technical
Committee on Operating Systems, are creating related standards in areas
like windowing toolkits.  While POSIX started with UNIX as a model,
POSIX standards are not limited to UNIX.  For example, DIGITAL has
announced a program that will incorporate some of the POSIX standards
into VMS.  Once adopted and implemented, POSIX standards will define a
broad range of compatibility both within the UNIX family of operating
systems and between other operating systems.

POSIX and FORTRAN

What follows is the January 1991 report on the progress of one of the
POSIX working groups, POSIX.9.  POSIX.9 is responsible for defining
FORTRAN interfaces to the POSIX functionality defined by the other
working groups.  As a member of this committee I need to keep track of
the progress of other committees to anticipate the next set of
interfaces we will have to develop.  At the moment there is only one
published POSIX standard, which is referred to as POSIX.1. POSIX.1
defines the functionality and C interface to POSIX operating system
services.  POSIX.9 is currently in public review with a standard that
defines FORTRAN interfaces to the POSIX.1 system services.  In addition
to providing interfaces to system services such as process creation and
interrupt handling, the draft also defines interfaces that will improve
FORTRAN application portability and interoperability.  For example, the
draft contains procedures for reading the command line arguments,
performing stream I/O, inheriting open files, getting the time of day,
access to system constants, access to system structures, and performing
bit operations.

``Thick'' versus ``thin''

The FORTRAN binding to POSIX is referred to as a ``thin'' binding.
That means that it defines the FORTRAN interfaces to access the POSIX
system services, but does not define the functionality of those
services.  Instead, the FORTRAN binding references the POSIX.1
standard for the functional definitions.  The Ada binding to POSIX is
also nearing completion.  It is a ``thick'' binding, in that it
defines both the Ada interfaces and functionality.

There are advantages and disadvantages to each approach.  Thick
bindings are easier to read, since all the information required is
contained in one document.  Also by using the thick approach it is
easier to map the functionality into native-language constructs.  The
Ada-bindings group has done just this and has been praised for
producing a binding that is very Ada-like (as opposed to C-like).

Thin bindings constitute a more conservative approach.  Since
functionality is not defined in the thin binding, there is no
opportunity for errors or inconsistencies to be introduced.  Also, thin
bindings are easier to adapt to changes in the base document.  For
example, the FORTRAN binding currently references the 1988 version of
POSIX.1.  Recently, however, POSIX.1 has been updated (1990) with
several changes to functionality.  After careful analysis at the
January meeting, we determined that the FORTRAN binding requires only
one substantive change to reference the 1990 standard as the base
document.

ISO Requires Language Independence

The International Standards Organization (ISO) at one time required all
POSIX functionality to be specified by language-independent standards.
These are standards that specify functionality without specifying
interfaces or syntax.  Thin binding standards are then produced for
each language to provide access to the functionality.  In the last
year ISO has relaxed this restriction to allow thick C bindings that
define new functionality, but has excluded all other language bindings
that do not reference a language-independent standard.  Even though
the FORTRAN binding is a thin binding it is based on the thick C
binding and not a language-independent specification as ISO requires.
This is because there is no language-independent specification and
such a specification could be a year or more away.

As a consequence, our working group will forward our draft for IEEE and
ANSI processing when our work is complete.  We will also ask ISO if
they wish to adopt the IEEE standard at that time.  This will give ISO
another chance to say yes or no.  We hope that they will adopt our
binding at that time.  If not, it may be several years before a
language-independent standard is developed and we can produce a binding
to it.  We feel that our binding has usefulness in the FORTRAN
community today, so that an ANSI standard even in the absence of an
ISO standard would be useful.

Other issues

Other issues discussed at the January meeting included Fortran 90, the
ballot process, and testing.  There was some discussion of whether the
POSIX.9 draft standard was Fortran-90-compatible.  Since the FORTRAN
binding to POSIX only requires FORTRAN 77 features it was agreed that
our binding should be compatible with Fortran 90 compilers.  We will
look into this more carefully; however, after reviewing the areas in
which Fortran 90 defines aspects for FORTRAN 77 that were previously
undefined, I am confident that there are no conflicts that would
prevent our binding from executing properly in a Fortran 90
environment.

I presented a short summary of Fortran 90 features to the working
group.  There was a discussion of which Fortran 90 features might be
used to increase the usability and portability of the Fortran
binding.  There was interest in using derived types and user-defined
operators to create an unsigned data type for Fortran - complete with
the necessary mathematical operations.  There was also an opinion that
we should limit the Fortran 90 features we use to those already in
existence in common practice (e.g., structures and Include).  This
would have the advantage that our Fortran 90 binding would not require
a full Fortran 90 implementation and the disadvantage of not making
the most of Fortran 90 features.

When this is printed we will be processing public ballot comments.  The
IEEE procedures for processing these comments was explained to us at
this meeting.  In order for our balloting to be successful, the
following criteria must be met;

  1.  we must receive back at least 75% of the ballots sent out and

  2.  75% of the yes-plus-no total must be yes.

Ballots received will be of one of three types, yes, no, and abstain.
If there are any no votes we are required to send out the objections to
all those in the ballot group.  They will then have the opportunity to
change their vote.  We will make changes to the draft and repeat this
process until the necessary 75% is met and there are no new objections.

We discussed writing test assertions for our current draft.  These
assertions are used by an implementor to prove conformance to the
standard.  It was agreed that, since the FORTRAN bindings is a thin
standard, our test assertions would be a thin document.

Work to be done

There is still much work to be done.  At our next meeting we will be
processing the public ballot.  We hope to a have a diverse range of
opinions.  We are hoping that an active balloting group will improve
the quality of the standard.  In this way, problems can be detected and
fixed before they become part of the standard.  If all goes well, that
could be as soon as December 1991.

Our next meeting will be in Chicago in April and you are welcome to
attend.  After that we meet in Santa Clara in July.  [jsh -- Note that
I changed this.  Am I right?] Please contact either John, Loren, or me
for details.

John McGrory (Chair)
Hewlett-Packard
19447 Pruneridge Ave
Cupertino, CA 95014
[e-mail]
[phone]

E. Loren Buhle, Jr., Ph.D.
University of Pennsylvania School of Medicine
Rm 440A
3401 Walnut Street
Philadelphia, PA 19104
[e-mail]
[phone]

Joseph J. King, Ph.D.
Genetics Computer Group
575 Science Drive, Suite B
Madison, WI 52711
[e-mail]
+1  [phone]





















































March 26, 1991 Standards Update                 1003.9: FORTRAN Bindings




POSIX .1 First published as IEEE 1003.1-1988, this standard has now been
    revised and updated, and achieved international status as ISO/IEC
    9945-1 : 1990(E).



Volume-Number: Volume 23, Number 20