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.