Draft NCEG minutes
Linda Stanberry
uunet!ocfmail.ocf.llnl.gov!linda
Sat Oct 5 12:48:17 PDT 1991
NCEG attendees:
Following is a draft of the minutes of the Cupertino meeting. Please review
for accuracy--if I have misrepresented or omitted details, now is your
chance to correct them! (No misrepresentations were deliberate, but I
may have dozed off during an important discussion, or paraphrased your ideas
incorrectly...) The appendices referenced are not available yet, but will
be included with the real minutes.
Linda
-----------------------------------------------------------------------------
D R A F T
---------
NCEG 91-045
Minutes of X3J11.1 Meeting #1
(NCEG Meeting #6)
24-27 September 1991
Apple Computer, Inc.
20525 Mariani Ave.
Cupertino, CA 95014
Attendees
Curley, Farance, Frankel, Hansen, Hashemi, Hoffman, Homer, Hough,
Jaeschke (Chair), Jervis, Keaton, Kohlmiller, Kwan, Lewis, T. MacDonald
(Vice Chair), S. McDonald, McMaster, Meyers, Prosser, Sabot, Schwartz,
Stanberry (Meeting Secretary), Swan, Swift, Thomas, Tydeman, Weidenhofer
1. Opening activities (Jaeschke)
1.1 Opening comments, goals and purpose of the meeting
The meeting was convened at 9:00 a.m. on Tuesday, 24 September 1991, by
Chairman Rex Jaeschke. Tom MacDonald acted as Vice Chairman. Linda
Stanberry acted as secretary.
Jaeschke informed the committee that NCEG had been formally approved as
X3J11.1, making this our first official meeting, although it was the
sixth meeting of NCEG. First meeting procedures were discussed and
are reported under item 2 of these minutes.
Goals of the meeting were to continue reviewing documents of each
subgroup, giving detailed review of those near convergence, with the
aim of making those documents ready for public review in 1992, and
eventually ready for publication as a Technical Report (TR).
1.2 Host facilities
The host for the meeting was Apple Computer, Inc. Thomas informed
the group of local facilities and arrangements for the meeting.
1.3 Approval of previous minutes [NCEG 91-011]
Minutes of the 5th meeting (Norwood, MA, March 1991) were approved
without change.
1.4 Status of action items from previous meetings
* (NCEG 90-019: F. Farance will gather examples of vector-calculation
kernels for exercising the array-syntax proposals.) Still pending.
* (NCEG 90-019: F. Farance will prepare a convergence plan for the
array-syntax subgroup.) Still pending.
(NCEG 91-011: R. Jaeschke will monitor the X3 approval vote for NCEG.)
Jaeschke reported that NCEG had been approved formally as X3J11.1.
(NCEG 91-011: R. Jaeschke and T. MacDonald will ensure that NCEG
minutes and other documents reach ISO/SC22/WG14.) These documents
were submitted.
(NCEG 91-011: T. MacDonald will look into the possibility of
establishing an NCEG e-mail distribution site.) This facility was
established as ncegacray.com. Curley announced the following e-mail
distribution sites for parallel NCEG issues: nceg_paraconvex.com
and nceg_par-requestaconvex.com (requests to add/delete from mailing
list).
(NCEG 91-011: R. Jaeschke will send Vouk network material regarding
PCF/X3H5.) Done.
(NCEG 91-011: B. Gottlieb will send NCEG (MacDonald) the latest version
of the X3H5 model description.) MacDonald received and distributed
NCEG 91-008 and 91-012.
(NCEG 91-011: R. Jaeschke will present a summary of Gottlieb's
presentation to X3J11.) The summary was presented at the March 1991
meeting.
(NCEG 91-011: D. Prosser will prepare a presentation on Ritchie's VDA
approach for the next meeting.) Prosser announced Ritchie planned to
attend this meeting to make the presentation.
(NCEG 91-011: M. Jaffe will prepare a list of LCAS functions that
should be considered for the Floating-Point C Extensions.) Done,
NCEG 91-017.
(NCEG 91-011: R. Meyers will write a paper on compatability issues
related to change in the sizes of int and long.) Done, NCEG 91-018.
(NCEG 91-011: R. Jaeschke will submit information on Convex long long
implementation.) Done, NCEG 91-014.
(NCEG 91-011: R. Jaeschke will broadcast the next mailing deadline
and the future meeting dates.) Done.
(NCEG 91-011: J. Thomas will send additional information regarding
the meeting.) Done, NCEG 91-016.
(NCEG 91-011: R. Jaeschke will develop and revise agenda from existing
subgroups' action items and requests.) Done, NCEG 91-030.
1.5 Approval of agenda [NCEG 91-030]
Changes to the agenda were proposed to include discussion of new
papers from Stallman and Kahan. Additional papers for agenda items
were identified. The items in the minutes do not necessarily reflect
the order of presentation, but are organized by subgroup.
Frankel requested that the agenda reflect evening subgroup meetings.
Thomas announced that the FP/IEEE subgroup would meet Tuesday evening,
7-10, in the conference room at the Cupertino Inn. Farance announced
that the array syntax subgroup would meet Wednesday evening, starting
at 7, at the Cupertino Inn.
A The committee accepted the revised agenda.
1.6 Introductions
Attendees introduced themselves and subgroup focal points were identified.
An attendance list was circulated (Appendix I).
1.7 New documents
New papers were assigned numbers and available documents were distributed.
91-032 "Comments on Extended Integer Ranges," Schauble, distributed.
91-033 "Alternate Syntax for FLoating Point Extensions," Stallman,
distributed.
91-034 "Variable Length Array Parameters: Resolving the Dilemma," Stallman,
distributed.
91-035 "Proposal New Work Item Language Compatible Mathematical Procedure
Standard," LCAS, distributed.
91-036 "Proposal New Work Item Language Compatible Complex Arithmetic and
Procedure Standard," LCAS, distributed.
91-037 "Revision Ideas for 'Floating-Point C Extensions'," Stallman,
distributed.
91-038 "FIPS PUB 160, Announcing the Standard for C," FIPS, distributed.
91-039 "Augmenting a Programming Language with Complex Arithmetic,"
Kahan, distributed.
91-040 "Proposal for Vector Operations according to the IEEE Standards
for Binary and Radix-Independent Floating-Point Arithmetic,"
Knofel, distributed.
91-041 "Floating-Point Modes and Status," Hough, distributed.
91-042 "Contracted Multiply-Adds," Kahan, distributed.
91-043 "Putting UNIX on Very Fast Computers or What the Speed of Light
Means to Your Favorite System Call," O'Dell, distributed. (This
is an excerpt from this paper.)
91-044 "Comments on Kulisch/Miranker," Demmel, distributed.
91-045 "Minutes of X3J11.1 Meeting #1, NCEG Meeting #6," Stanberry, this
document.
2. Officers, membership, and voting (Jaeschke)
Jaeschke discussed "first meeting" procedures. This included establishing
officers, and clarifying membership and voting.
Officers: Chairman and Vice Chairman are required, and international
representative is recommended. Jaeschke has applied to X3 for position
of chair, and MacDonald has applied for position of vice chair. X3 met
on 20 September; Jaeschke learned by meeting end that his application
as chair had been approved, but there was no word yet on vice chair.
Since no one has applied for IR position, and since we are a subcommittee
of X3J11, it is not critical to fill this position. Jaeschke noted that
he is the IR for X3J11, so will be able to represent NCEG through that
role as well, but cannot be NCEG IR since he is already an NCEG officer.
Membership: NCEG (X3J11.1) members are now required to formally join
(pay dues) through CBEMA. Membership in X3J11 is recommended, since you
pay the same dues, but you can join only the subcommittee if desired.
Regardless of which you opt for, separate attendance and voting rights
will be maintained for J11 and J11.1. It is the duty of the vice chair
to notify members when their voting rights are, or are about to be,
forfeited due to non-attendance. These are the same rules as for X3J11.
Voting: members who have attended 2 of the last 3 meetings can vote on
formal decisions. The primary or alternate can vote, but CBEMA needs
to be notified of changes in member representation prior to the
meeting in which they are to be in effect.
Curley asked for clarification of whether observers of X3J11 can vote in
NCEG. Yes, since separate attendance records will be kept. It was noted
that observers pay the same fees as voting members.
Jaeschke noted the following procedures which are required now that we
are formally an ANSI subcommittee:
--required to notify CBEMA of meeting schedule;
--required to have a project proposal;
--required to identify, notify, and coordinate with ANSI committees
doing similar work; must form liaisons with these groups.
Some discussion followed on coordination with other committees (Thomas,
Prosser). It was noted that our charter was to build on ANSI C.
3. Liaison reports
3.1 X3J11, ISO/SC22/WG14 (Jaeschke)
Jaeschke explained the letter ballot to replace ANSI C with the ISO C
standard. Prosser explained the differences in the two documents:
they are identical in content, except for numbering/division into
sections, and text in footnotes; there is a mechanical mapping between
the two. Other differences between the documents is the absence of
line numbers and the rationale in the ISO document. Discussion of
availability of the rationale as a separate document, or future inclusion
in the ISO document followed.
* Jaeschke will ask Jim Brody (X3J11 Chairman) about the availability of
the rationale.
Jaeschke reported that Brody informed him that the ISO document is
scheduled to replace the ANSI document in May '92; X3J11 will continue
to reference both document numbers, however, since many in the C
community will not have the ISO standard.
Prosser reminded NCEG of X3J11's decision at the Norwood meeting to
allow wider format store of FP constants, which is now reflected in
the FP/IEEE document.
Jaeschke reported that the ISO rappoteur group that had been proposed
by WG14 could not be formed, but that they do support the work of this
committee.
Jaeschke had reported NCEG work and issues to WG14 at the Japan meeting
in June. At this meeting the issues of alternate spellings of trigraphs
was raised again. Tom Plum (X3J11 Vice Chairman) developed a proposal
that was accepted to allow new trigraph alternates, with details on how
they will coexist with existing C phases of translation. This will
have an impact on NCEG proposals.
* Jaeschke will distribute Plum's proposal to NCEG.
3.2 X3J16 (Swan)
Randall Swan reported on the status of the C++ standards committee.
Compatability issues between our two committees were mentioned: VDAs,
exceptions, header files. Thomas asked about scope of libraries;
official "classes" for complex? Probably not, since formidable task.
MacDonald asked if they are addressing aliasing? Not yet, still working
on basics. Jaeschke noted that the ISO C++ committee plans to hold
joint meetings with the ANSI committee, and an I-project will be
proposed.
3.3 X3H5 (Curley)
Austin Curley reported on progress being made in formalizing ideas.
Concern about possible Fortran bias was noted--e.g., assumptions about
loop counting and aliasing. Future meetings and public review schedule
were outlined--they hope to have Fortran binding available after the
March '92 meeting, but no C binding by then. The Fortran 90 community
is asking for extensions. C concepts such as storage duration, scope,
and linkage need to be addressed. Reassurances were given that the
consensus of X3H5 is to be compatible with X3J11. E-mail contacts were
reported: x3h5acs.orst.edu, and ruddacs.orst.edu (Walter Rudd).
Prosser asked about their actual charter; concern that it leaves many
details to other committees. Jervis asked whether they were considering
alternate models (e.g., distributed memory). No, but NCEG and POSIX
groups are attempting to address this issue.
Curley summarized the question facing X3H5 and others as: do we want to
design a proposal to make it possible to support parallelism in existing
languages with minimum changes, or design a new language for parallel
applications?
3.4 X3T2, LCAS (Jaeschke)
Jaeschke reports that Jaffe has been reassigned and no longer is working
with LCAS. However, because of considerable negative response to the
current LCAS proposal, believes X3T2 has voted to revise their proposal.
Prosser asks how can we coordinate without a liaison? Jaeschke suggests
we are already "overtasked."
3.5 IFIP 2.5 (Vouk)
No new activity reported.
3.6 POSIX (Prosser)
No new activity reported.
3.7 DSP (Hoffman)
Marc Hoffman reported that Analog Devices now has a working
implementation of their DSP proposal.
4. Technical report closure, next meeting, draft distribution (Jaeschke)
We were reminded that this meeting and next were scheduled for extra
days since we weren't meeting with X3J11, in order to facilitate careful
review and finalization of documents near convergence. Need to identify
what needs to be discussed further at the next meeting from what is
left over from this one.
Discussion of draft TR distribution followed. Suggested to distribute to
X3J11, X3J16, X3H5, etc., initially, and later to distribute for public
review after appropriate revisions from feedback from these committees.
The mode of the draft distribution was also discussed: use mail, not
e-mail to distribute, and provide in postscript on a floppy for the
ISO community.
Discussion followed about the form of the actual TR--no ANSI requirement
so we are free to choose whatever form we want. For now each subgroup
is working independently, and we may publish proposals independently.
MacDonald asks how to make clear the possible interactions between
independent proposals. More discussion followed (Prosser, Frankel,
Thomas), and consensus was that we need to be careful not to produce
mutually conflicting proposals.
5. Aliasing (Homer) [NCEG 90-043, NCEG 91-024]
Bill Homer presented CRI's proposal for restricted pointers, NCEG 90-043
and 91-024. A further revision of the formal definition was presented.
Homer also presented the copy in/copy out paradigm as what the user
wants, but of course, with unnecessary copies detected and removed by
the compiler. Restricted pointers declare to the compiler that they
are safe for using in this paradigm without the copying. Homer's
summary of this presentation is attached as Appendix II.
Much discussion followed (Prosser, Frankel, Farance, Jervis, MacDonald).
Prosser restated opposition to use of type qualifiers to handle aliasing.
Main problem is finding a way to assert that function array parameters
are disjoint.
Frankel suggested other approaches can be used to tell the compiler
the needed assertions--the "assert" macro or C* assertions. Farance
suggested that assertions are not easy or concise to express.
Prosser repeated that type qualifier use has all the problems of the
"noalias" proposal approved but later rescinded by X3J11. Jervis noted
that the volatile type qualifier does give prior art in use of a type
qualifier for qualifying implementation optimizations; use of type
qualifiers cannot change semantics of a correct program.
With respect to the formal definition and examples in the papers, the
discussion raised questions of when undefined behavior results. The
wording in the proposal is open to interpretation. Argument over what
are disjoint objects; clarification is needed.
Stanberry asked that issues and goals be identified for this subgroup.
Suggestions heard included: (1) adopt restricted pointer proposal with
refinements to handle noted ambiguities; (2) determine if type qualifier
mechanism will be acceptable to X3J11 and Ritchie; (3) evaluate Ritchie's
VDA proposal as an alternative; (4) examine new scope assertion mechanisms;
(5) reconsider #pragma disjoint as proposed in NCEG 90-025; and (6) develop
assertions only for function parameters. Except as noted in the action
items below, no clear consensus was reached; however, there did not seem
to be any support for (5) or (6) at the current time.
* Prosser will produce a paper detailing how Ritchie's VDA proposal also
addresses and solves the aliasing issues.
* MacDonald will develop criteria for evaluating aliasing issues from
contributions sent to him.
6. FP/IEEE (Thomas) [NCEG 91--028, 91-033, 91-037, 91-041]
Jim Thomas presented Stallman's proposal from NCEG 91-033. This proposal
wants to avoid the use of #pragmas since they cannot be used in macros
nor in other contexts where they might be useful. Suggested mode
assertions that can occur in declarations or as casts in expressions.
Considerable discussion followed (Prosser, Frankel, Meyers, Jervis,
Thomas, Homer, MacDonald). This proposal obviously impacts the FP/IEEE
proposal. It introduces new semantics for casts, which are unclear at
present. Granularity of mode assertions is also not clear. It is
consistent with static FP modes, which are preferable to dynamic modes.
Several straw votes were proposed for possible action on the proposal,
but none were completed. In general, it was deemed too difficult to
revise the FP/IEEE document for the draft TR because of time constraints.
Consensus of the committee was to ask Stallman to refine the ideas in
this proposal and to encourage his continued participation in this
area. Thomas will contact him with our feedback and list of concerns.
Thomas presented current FP/IEEE document, NCEG 91-028. Goals were to
make a thorough review of this document, page by page, to get comments,
identify revisions already made and incorporate suggested new changes,
and to develop a list of issues that still need to be addressed.
The committee reviewed the entire document, and changes with respect
to form and content were discussed and accepted. Thomas provided a
summary of the issues identified as needing more review at the next
meeting which is included as Appendix III. Other changes agreed to will
be reflected in the next version of the FP/IEEE document.
In discussing section 4.2.2.2, the issue of preference for NANS vs. SNAN
as the syntactic designation of a signalling nan was raised. An opinion
poll for changing the proposal from NANS to SNAN or some other spelling
was taken. 8 preferred to leave as NANS, 2 preferred to change to SNAN,
and 1 preferred SIGNAN.
Major issues that underlie most of the issues include generic intrinsic
functions, static vs. dynamic modes, and interface portability (what has
to be provided).
Further discussion of generic intrinsic functions. Prosser suggested only
trying to apply to math functions; borrow concepts from C++ overloading,
and develop rules for duplicate declarations encountered after including
<math.h>. Meyers observed that we may do a disservice to the C
community if we don't address the generic function issue in general.
Jervis comments that to adopt generic functions would be a radical
philosophical departure from C!
* Thomas agreed to begin trying to incorporate a proposal for generic
intrinsic functions into the FP/IEEE document.
Further discussion of static vs. dynamic modes. Dynamic is current art,
but static analysis would be great benefit to compiler writers and to the
size of the FP/IEEE document: there would be no need for runtime state
and functions to manage it.
7. Complex [NCEG 91-026, 91-039]
MacDonald presented NCEG 91-026, noting revisions from previous proposal
(91-005).
Prosser raised the question of why restrict the ordering for the i
suffix; order of other suffixes is not restricted.
SV Should the proposal retain the restriction that the i suffix must
appear last? 5 yes, 11 no, 2 undecided.
Discussion of whether to allow j as well as i as an imaginary suffix
followed.
SV Should the proposal retain only i as an imaginary suffix?
11 yes, 2 no, 5 undecided.
The issue of requiring inclusion of <complex.h> was raised: do we
want to fix the underlying keyword? Consensus was not to do so at
this time, and that proposal needs more clarification and cross-
referencing of the use of <complex.h>.
The next discussion (Hough, Jaeschke, Kwan, MacDonald, Prosser, Schwartz)
centered on error handling in complex functions. Although the proposal
states that none of these functions use errno, an implementaton is free
to use underlying <math.h> functions which do use errno, which could be
misleading. It was suggested that the proposal should not use the
terms "range" and "domain" errors, since that implies ERANGE and EDOM
assignments to errno. Compatability with IEEE and C++ was raised. An
attempt to formulate a straw vote was made, but the issue was postponed
to discussion of exception handling.
MacDonald asked if there is a need to specify ordering of real and
imaginary parts, pointing out that Fortran does specify the order. The
issue of C++ compatability with old style C function declarations was
raised. Compatability with Fortran complex was suggested as perhaps
more important. No clear consensus was formed.
Thomas introduced a proposal from Kahan to allow relational operators
other than equality to be applied to complex objects: if a and b are
complex objects, a < b if cimag(a) == cimag(b) and creal(a) < creal(y);
otherwise a and b are unordered. There were several objections to this
proposal. MacDonald requested that futher input be sent to him on what
operators should be allowed on complex objects.
Kahan's proposal for an imaginary type was discussed, NCEG 91-039. This
solves the problem of a constant such as 1i introducing a real 0, which
can lead to expression evaluations which conflict with IEEE expected
results. The question was raised that if we like the idea of an
imaginary type, should it be restricted as in Kahan's proposal for use
only in expressions, or should we allow it as any other type--i.e.,
allow variables of this type, etc.
SV Is there sentiment for having some form of imaginary type?
5 yes, 5 no, 10 undecided.
8. Array syntax (Farance) [NCEG 91-023, 91-027]
Frank Farance announced that the agenda time for the subgroup would be
used to hear presentations from Hansen and Frankel, and to discuss future
goals.
Frankel volunteered to replace MacDonald as secondary focal point for
this subgroup.
Ken Hansen of MasPar presented an overview of their implementation of
MPL, an extended version of C for their systems (NCEG 91-027). Parallel
versions of C operators were illustrated. Parallel communications,
memory allocation, library functions, and statements were described.
MPL has "replaced" assembly language on their system. Current plans are
to develop an improved, ANSI-based version for future systems, MPC. This
will allow users to specify arbitrary "shapes," rather than
broadcasting to all PE's. Details will be in a forthcoming paper.
Hansen also presented a summary of contasting MPL and MPC with C* and
CRI's proposal (referred to as "[;] C") for expressing parallel
declarations and operations.
Jamie Frankel very briefly described the C* Language Reference Manual
(NCEG 91-023).
Frankel then proposed "what direction do we want to take?" General
discussion ensued (Farance, Frankel, Hansen, Kohlmiller, MacDonald,
Prosser) to address what we perceive as needed by the C user community.
Straw votes from the Norwood meeting were reviewed. "Users don't want
to write loops" was one suggested paradigm. It was also noted that
algorithms rewritten for data parallel models will usually perform better
even on scalar architectures. General consensus was that we needed to
compile a set of criteria to evaluate the proposals from this subgroup
and to use as benchmarks.
* Farance will develop criteria to measure the proposals in consultation
with array syntax subgroup members.
Further discussion suggested that the criteria should include being
able to treat arrays as first-class objects, or something very close:
what operations do we want to allow and how efficiently can they be
expressed? Concern was expressed about whether it is too early to
standardize on MPP ideas.
Jaeschke proposed that the January meeting devote one full day to this
subgroup, but that we would need a document with a summary and a
rationale to aid discussion. Noted that no NCEG document provides
the history of this subgroup as yet. Farance will attempt to acquire
input for criteria in time to produce a document addressing this for
the next mailing.
9. Exceptions (Hough) [NCEG 91-041]
Dave Hough briefly reported on his and Kahan's views on the FP/IEEE
proposal with respect to exception handling (NCEG 91-041).
The issue of whether or not the FP/IEEE proposed functions should
specify use of errno was discussed. Consensus was to leave unspecified.
Several other issues were briefly touched on, but time did not permit
in-depth discussion of any: standardizing diagnostics to be issued and
sent to stderr (like an atexit()); local exceptions to allow detection
and handling of an exception in, say, the scope an expression; using
presubstitution in exception handling.
Hough indicated he would forward non-controversial items to Thomas for
inclusion in the FP/IEEE document.
10. Variable Dimensioned Arrays [NCEG 90-041,91-029, 91-034]
Dave Prosser reviewed the proposal from Ritchie, NCEG 90-041, in his
absence. The thrust of this proposal is that a mechanism is needed to
inform the compiler of the acutal dimensions of a multi-dimensional
array argument to a function so that compilers can generate efficient
index computations. The proposed solution is to syntactically designate
such arguments to indicate they are variably dimensioned, and to pass
"fat" pointers that implicitly contain the dimensions. This was
contrasted with the restricted pointer approach which requires users
to explicitly pass the dimensions. This proposal requires changes only
to semantics of void *'s and sizeof expressions, in addition to handling
the new parameter syntax. In particular it does not require any changes
to the type mechanism. Prosser will develop examples of uses of this
proposal for next meeting (see action item under section 5 of these
minutes).
MacDonald presented the revised proposal for restricted pointers, NCEG
91-029. This proposal suggests a type extension to allow variably
dimensioned arrays in block and function prototype scopes, except not
as struct or union members. This allows compiler optimizations in
contexts other than those involving function parameters. MacDonald
discussed changes from the previous version, and presented the following
revision of the method of determining identifier bindings within
parameter-type-list's in section 3.5.4.3:
In each parameter-type-list involving variable length array types,
there must exist a permutation of the parameter-declarations in
which a declaration is visible for each instance of an identifier
in a size specifier, and the association of identifiers with
objects is determined by the permuted order. If two different
permutations result in different associations, then the behavior
is undefined. In a parameter-type-list that is not part of a
function declaration, an asterisk may be used in place of a size
specifier, since the value of the specifier is not required.
The issue of allowing relaxed ordering of declarations within a
parameter-type-list was discussed. Stallman's proposal for solving
the "forward" referencing problem within parameter-type-list's was
also discussed (NCEG 91-034).
SV In favor of preserving lexical ordering, 7.
In favor of relaxed ordering, 7.
Undecided, 2.
SV Shall we pursue Stallman's proposal further? 4 yes, 5 no, 6 undecided.
MacDonald reported that CRI's latest C compiler has the restricted
pointer implementation.
11. Extended integer range (Meyers) [NCEG 91-010, 91-014, 91-018, 91-032]
Randy Meyers led the discussion in this area, beginning with the
proposal that this subgroup try to identify "deliverables." He
suggested at least the following four: (1) A discussion of compatability
issues that arise with integral types of >32 bits (NCEG 91-018);
(2) Alternative syntax for integer types, to allow designating bit/byte
size (NCEG 91-032); (3) Developing a new <ints.h> header file to contain
standard names for extended integer types; and (4) Description of how
long long is used (91-014).
Meyers presented his paper addressing the first area, NCEG 91-018. There
was much discussion (Farance, Jervis, Keaton, Prosser) of implications
for users' code with the evolution of integer types to >32 bit sizes.
There was considerable sentiment that long type needed to grow to >32 bits
for current applications already. Of the 5 scenarios detailed in Meyers'
paper, #1 introduces the least change for standard types, affecting
only the range requirements for int type (increasing from 16 to 32 bits);
the remaining scenarios require more comprehensive changes. The question
was raised which approach should NCEG support, #1 or #2-5?
Paul Schauble's email comments (NCEG 91-032) were discussed next. The
following issues were raised. Should user-specified integer types map
onto a C defined type, and then follow promotion rules for that type,
similar to bit fields? Should a user-defined type specify number of
bits for representation, or range of values to represent? Does a bit
specification imply using exactly that many bits, or a minimum? What
syntax is best? Jervis suggested that C change from a "3 integer type"
model to an "implementation-defined-number of integer type" model to
allow future enhancements. The need for bit arrays was discussed. No
clear consensus was formed on any of these issues.
The committee voted on the desirability of each deliverable.
SV Should there be a section of our TR addressing compatability of >32 bit
integers? MacDonald requested that this section be a rationale rather
than a specification.
0 opposed.
SV Should there be a section on type specification syntax?
9 yes. 1 no. 6 undecided.
SV Should there be a section on an <ints.h> header file?
9 yes. 3 no. 5 undecided.
SV Should there be a section providing guidance for long long's?
13 yes. 1 no. 3 undecided.
* Meyers will continue to write or coerce others to write papers
addressing these issues.
12. Administration (Jaeschke)
12.1 Summary of decisions reached.
No summary given since all votes were straw polls, no formal decisions
reached. Straw votes are indicated by SV in the left margin of these
minutes.
12.2 Action items committed to
Stanberry reviewed the action items, which are marked with * in the
left margin of these minutes.
12.3 Future meeting schedule
7-10 January 1992 in Plano (suburban Dallas), Texas. Convex will be
the host. Curley indicated that the meetings will probably be held at
the hotel facilities, which are described in NCEG 91-031.
11-12 May 1992 in Salt Lake City, Utah. Decus will be the host. This
will precede the joint X3J11/WG14 meeting on 13-15.
7-8 December 1992 in Washington, D.C. This will be held at the CBEMA
facilities, and will precede the joint X3J11/WG14 meeting on 9-11.
There was some discussion of the possibility of future separate
meetings or other ways to get additional time, such as meeting on a
weekend day before or after the regular meeting.
Jaeschke will develop a revised project schedule to reflect our current
status and goals.
Farance, MacDonald (Cray), and Kohlmiller (CDC) indicated possible
hosting of meetings in 1993.
12.4 Mailings and submission procedures
There will be only one mailing before the next meeting because of the
short time between meetings. Send all submissions to:
Tom MacDonald
Cray Research, Inc.
655F Lone Oak Drive
Eagan, MN 55121
(612) 683-5818
tamacray.com
uunet!cray!tam
The deadline for submitting papers is 16 November 1991.
* MacDonald will post mailing procedures for the next meeting.
* Jaeschke will post information explaining the necessity to get papers into
the mailings, or delivered at least two weeks before meetings (i.e.,
providing own mailing), in order to have agenda time to discuss a
proposal.
12.5 Next meeting agenda
Curley advised that subgroups can arrange for rooms for their meetings
through him.
Each subgroup will be scheduled agenda time.
Prosser asked for time to revisit the initialization proposal (NCEG
90-035). Jaeschke will schedule one hour for this.
12.6 Other business
The committee thanked Thomas and Apple Computer, Inc., for hosting the
meeting.
Other issues which were raised and discussed under this agenda designation
have been reported under the appropriate subgroup or other section
of these minutes.
12.7 Adjournment
The committee adjourned at 11:45 a.m.
More information about the Numeric-interest
mailing list