JTC1/SC22/WG14
N994
Minutes for the Embedded C PDTR ballot resolution meeting
WG14/N994
19-Nov-2002
Tuesday, 15 Oct., 09:20
** DE #1:
It was decided in Curaçao that we lack the technical knowledge to
extend the types. Also, most financial applications, which would
use fixed-point decimal types, tend to be written in C++, not C.
** NL #1:
The intent is that unsigned fract + int will be unsigned
because the result is the fract type. The rule that
signed + unsigned is signed applies only when both types
are fixed-point.
** NL #2:
We're allowing int + fract for orthogonality, especially for
machine-generated code. We'll put something in the rationale,
or have a footnote that explains that, yes, we know it's silly.
** NL #3:
Same as US #14. We will supply lib function or macro.
** NL #4:
Same as US #16. Defer to discussion of rounding.
** NL #5: concept of contracted expression. Do we want
something similar for fixed-point?
Because of the way floating-point operations work, it's possible
to get a different answer if you do a contracted multiply/add.
It's not just a matter of speed. With fixed-point, if the issue
is efficiency, the compiler already has permission to do what's
desired. If the only difference between a contracted operation
and the operation done with two expressions is rounding, the
compiler is allowed to do the optimization.
We will put words into the rationale.
** NL #6: about 2.1.6.2.1, next to last paragraph.
Special treatment of +1 and -1 as results
of multiplication...confusing.
The special case of multiplying -1 and -1 is what some DSP
hardware will, in fact, do. The purpose of the special case
is to allow users to write code in the most natural way and
allow compiling for those DSPs without tripping up over the
special case.
Users write
fract a[], b[];
long accum sum;
for (...) {
sum += (long accum)a[i] * b[i];
}
to do a dot product. Many DSPs actually do
sum += (long accum)((sat long fract)a[i] * b[i]);
more efficiently, so we want to allow compilers
to generate the second form.
We will add words that this is discouraged and deprecated.
** NL #7:
Banks will supply example of unsigned fixed-point in fuzzy logic.
** NL #8:
The "default" overflow behavior is "the fastest" for use when
the user knows that no overflow can occur. Because we don't
know whether that means sat or modwrap, or indeed something else,
the behavior is undefined if overflow actually occurs.
** NL #9: memory qualifiers.
We agree with the comment and will add a constraint
to the effect that address spec. modifiers may not
be applied to members of structs or unions.
** NL #10: allows address space qualifiers to be
used on function arguments.
Named address spaces have a global nature, so they don't
apply to function arguments or autos. We need to see
some prior art before we want to allow this.
Same answer for pointers to functions. Not allowed for now.
** NL #11: processor register access. Allows
a kind of "global register."
Processors have some special-purpose registers
that we really need access to. See also US #32.
** NL #12:
See US #32.
** UK #1:
This document is a type 2 technical report, and so by definition,
we have no intent one way or the other.
We recognize that this comment represents the tip of a much
larger issue that can't be solved in this TR; but we feel
confident that WG14 will be taking it up in the near future.
** UK #2:
The comment is correct that these are not scalable; but
we can't fix that with this document.
** UK #3:
Q is already used. Alternatives: B K M V W Y.
Consensus: K. (Solves US 1, 3, 4, 5.)
** UK #4:
The comment is correct. This is a more general issue
that applies to all types.
** UK #5:
Accepted. Will be fixed as suggested.
** UK #6:
Accepted. Editorial.
** UK #7:
Should be undefined.
(See also US #23.)
** UK #8:
Agree...undefined. Also addressed in US #23.
** UK #9:
Also addressed in US #23.
** UK #10:
Accepted. Editorial.
** UK #11:
Accepted. Editorial.
Also, fix two variables with same name, p. Make one q.
** UK #12:
Make address space qualifiers keywords in the implementors' namespace.
** UK #13:
We agree that the statement is too vague.
Banks will provide words.
** UK #14:
Defer until discussion of IOHW.
** US #1, #3, #4, #5:
K instead of Q. See UK #3.
** US #2:
Intent is fixed + float == float.
** US #6:
Defer to issue author.
[From Tydeman next day: recommended practice, exactly n-1]
** US #7:
Editorial. Same as UK #10.
** US #8:
Editorial.
** US #9:
Accepted in principle. Defer to IOHW discussion.
** US #10:
This is a more general issue that should be dealt with in
the context of the whole language, not just embedded systems.
** US #11:
Accepted.
** US #12:
Defer until tomorrow.
** US #13:
Leave unsigned in.
** US #14 and #16:
Same as previous.
** US #15 and #17:
Agree in principle.
** US #18:
Accept in principle.
** US #19:
Accept comment.
** US #20:
Accept comment. A note somewhere is needed that there's
no default widening of types when passed to varargs functions.
Plauger: Say rather that vargs()' argument should specify
the real type being passed. Don't mention "widening."
** US #21:
Accept except for register.
** US #22:
Defer until tomorrow. [rejected, see NL 11]
** US #23:
Accept in principle. Wakker will supply words.
Wednesday, 16 Oct.
** US #24:
Accepted.
** US #25:
We will write a more abstract description for chapter 4
and put a more detailed description in the annex.
** US #26:
The pragma solution is merely a placeholder for what
will eventually go into the TR. Banks and Hauser will
come up with new syntax.
** US #27:
Kristofersen and Hauser will come up with new syntax.
** US #28:
Absent a list, we're not sure what to do with this.
Leave open for the time being.
** US #29a: [there are two comments numbered 29 by mistake]
We will create a new subclause 2.1.6.4.
** US #29b:
Editorial.
** US #30:
Accept.
** US #31:
Accept.
** US #32:
Accept.
** US #33:
Accept. "iohw_my_hardware"
** US #34:
Made moot by US #25.
** US #35:
Accept.
** US #36:
Reject.
Wednesday afternoon:
** NL #7 and US #13:
Propose +[sat] to full committee.
US #22, NL #11 and #12:
register __sr uint16_t sr;
Take to full committee.
Thursday, 17 Oct.
modwrap will be removed as a qualifier, we'll still have the pragmas,
and the decorated operators will be mentioned briefly in the annex.