<font size=2 face="sans-serif">Same for this part.</font>
<br><font size=2 face="sans-serif">Note that we have some issues we need
to look at (tagged with *AI* below for context):</font>
<br><font size=2 face="sans-serif">1) Rename the "generic" floating
types to something else like "classic"</font>
<br><font size=2 face="sans-serif">2) Jim's slide examples need to be added
to the TS</font>
<br><font size=2 face="sans-serif">3) The word "interchange"
should be replaced by something else</font>
<br>
<br>
<br><font size=2 face="sans-serif">n1691: (Floating point TS Part 3)</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Benito: C++ is working on some typedefs for extended types as well.
Bill Seymour will make sure they (C++) know that we have an ISO work item
for this already while they are still in a study group so we don't get
out of sync.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Issue 1:</font><font size=3> </font><font size=2 face="sans-serif"><br>
Blaine: What is the technical reason for having part 1 or
part 2 binding?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: The types requires arithmetic for use. We could have
the data interchange types without any binding to the previous parts.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Douglas: What is the point of the issue?</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: It is a distributed specification. How hard will this
be for implementers to follow these?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Benito: The downside started when we asked for Part 1 and
Part 2 to be independent.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Blaine: Why weren't the extended types put into part 1 and
part 2 themselves originally?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: These are optional from the IEEE spec. Parts 1 and 2
are mandatory from the IEEE spec.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Type structure additions:</font><font size=3> </font><font size=2 face="sans-serif"><br>
Blaine: Why do you want to have the distinction between data
interchange types and interchange floating types?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: An example is _Float16. Most implementations will want
this as a data interchange type. A particular may want to have arithmetic
operations on it as well making it an interchange floating type.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Clark: Representation is different from type. A type implies
representation and operations. It seems confusing to talk about interchange
types. It may be better to only have interchange representations.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: How do you get the representation?</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Clark: You can convert the representation to a type to handle
it. Maybe say transcribe instead of convert?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Tom: You do in fact define the data interchange types including
operations on the types. Which is being proposed?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: It will come later in the presentation. These are the
types you can put the representation into. You can do conversion, comparison
macros, etc. but not arithmetic.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: This is the type binding from IEEE to C.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Clark: You are renaming real floating types into generic
floating types.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Douglas: The paper changes all uses of real floating type
to generic floating type.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Clark: Why do this?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: Due to the decimal TR (now Part 2). The reason is to
keep real floating type wherever it is in the standard.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Clark: I don't like the connetations of "generic"
(Blaine also).</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: We can look at renaming this (*AI*) to maybe something
like "classic"?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Issues not labelled as issues (first so labelled slide):</font><font size=3>
</font><font size=2 face="sans-serif"><br>
No comments.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Example 2:</font><font size=3> </font><font size=2 face="sans-serif"><br>
Blaine: Is there some macro to know if _Float16 can also
be arithmetic?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: Yes.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Douglas: Why would you have _Float32x be 128 and not _Float64x?</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: It can be like the slide before.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: The types are distinct.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Barry: Should these tables (from the examples) be in the
TS?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: We can add them. (*AI*)</font><font size=3> </font><font size=2 face="sans-serif"><br>
Issues not labelled as issues (second so labelled slide):</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Seymour: How does float + Float64 work?</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: Promoted to Float64 since to do + Float64 must be an
arithmetic type</font><font size=3> </font><font size=2 face="sans-serif"><br>
Clark: I would prefer a world where this hierarchy or considerations
didn't apply. I would prefer the interchange stuff be in terms of representations
not types.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: That would not get rid of any of this. These are all
arithmetic types.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Clark: I would banish the concept of interchange type.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: What would float256 be?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Clark: I would not have one. No types.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: That is required by the IEEE standard.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Douglas: Can't you have all data types being arithmetic types?</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: That wouldn't help Clark.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Clark: The extended types are fine. The interchange types
is the issue.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Seymour: I've got a bunch of bits coming in my modem. I have
to put them in an object before I do anything with it.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Clark: I think of interchange as working on a buffer.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: I think you are tripping up on the name.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Clark: Yes, that and other things.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Blaine: You can make a typedef of a char array for those
types. You could have functions that work on those. And not have arithmetic
versions of the interchange types.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: The terminology is not being used right. The IEEE spec
allows data interchange types to be arithmetic.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Blaine: Is it possible to separate the arithmetic float16
to be distinct from the data only float16 (different names)? Would this
work with IEEE?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: We could then have the data only version handled differently.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Roberto: Is it possible to deliver the IEEE spec without
data only interchange types.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: This is a full specification of optional features of
the standard.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Martin: Are you opposed to the types being introduced as
fundamental types or even for "user defined" types (typedefs)?</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Clark: To talk about an interchange floating point type mixes
up ideas that do not help the world. The floating point standard says binary16
is an interchange type. That is a special case. I don't think the world
would thank us for this. People would want arrays of binary16 and operate
on them without pain.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: Suppose your implementation doesn't do computation in
float128 but wants to be able to handle it (for example, by converting
to float64x like 80-bit floats) to do actions on it.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Blaine: The interchange types should be distinct non-arithmetic
types with the exception of float16. The other interchange types should
never be arithmetic.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: The problem is terminology. The floating point spec
refers to all non-extended types as interchange types. (*Issue still*)</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Issues not labelled as issues (third so labelled slide):</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Blaine: Does the conversions include runtime code?</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: It could.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Martin: Do these types have to be fundamental types.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: These are scalar types. They cannot be structs. If we
want to respecify them we'd have to come up with new ways to do conversions
and classification macros etc. to make them functions.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Martin: Would doing those changes resolve Blaine and Clark's
objections?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Blaine: No, I don't want data only to be the same as arithmetic
types ever.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Issues not labelled as issues (fourth so labelled slide):</font><font size=3>
</font><font size=2 face="sans-serif"><br>
No comments.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Jim: Sensing reaction to the interchange terminology. We can go
back and change the terms we used for this.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Benito: Follows IEEE terminology.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Blaine: I want a reference to the IEEE description in this document.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Benito: It requires reading IEEE in the TS.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: We can look at adding or paraphasing the definition from the
IEEE spec for interchange terms.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Blaine: I need to understand the IEEE terminology and so I'll pull
back until I understand it.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Willem: I feel that interchange types are like jpeg. This is not
a concern for the language. Do we need to have them at all for C? Is it
appropriate for us?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Blaine: Interchange is nailed down. A specific number of bits for
mantissa, etc. so it can be used anywhere that follows the standard.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: If you think of it as data, it is interchangable data whether
or not you can do arithmetic. Email follow up on this item.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: The other concern is for the items that are not arithmetic
not be types.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Blaine: They need to be types, no question. Just don't put floating
in the name.</font><font size=3> </font><font size=2 face="sans-serif"><br>
Clark: You can think of them as struct types or model them as such.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Jim: Conversions make it interesting.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
Regards,<br>
<br>
Rajan Bhakta<br>
z/OS XL C/C++ Compiler Technical Architect<br>
ISO C Standards Representative for Canada<br>
C Compiler Development<br>
Contact: </font><a href=mailto:rbhakta@ca.ibm.com><font size=2 color=blue face="sans-serif"><u>rbhakta@ca.ibm.com</u></font></a><font size=2 face="sans-serif">,
Rajan Bhakta/Toronto/IBM<br>
Telephone: (905) 413-3995</font><font size=3> </font>
<br>
<br>