Fast track meeting July 12, 2004

Attendees
Jim Lewis
John Ries
Dave Bishop
Charlie Guy
Ryan Hinton
Karl Isnhoffer


Dave Bishop moderated discussion on the outstanding fixed point issues.

The first issue is how ranges are interpreted, especially with respect to
ascending ranges.Fixed point issues.  Rehash of the earlier e-mail post
occurred.  Dave pointed out choosing option 3 requires extensive package rework,
Option 2 and 1 do not.  Resolution was that ascending ranges should not be
used. Dave will look at determining the work to modify the existing packages so
that option 3 can be used.

Second issue is result size in addition and subtraction.
Should the result grow to preserve bits or remain fixed. Jim, Ryan, and Karl
believe that the result should grow. Question was raised if floating point
numbers have the same issue with growing. Dave's response is no this has to do
with the fact the floating point number of a number of properties such as
rounding and exponent size that don't allow sizing to be an issue. Resolution
was to make addition grow the result by one bit in the MSB position.

Third issue was result sizing of multiplication.
  Proposal posted in e-mail by Ryan will be used.

Issue 4, overloading of operators to allow mixing of signed fixed point (sfixed),
unsigned fixed point (ufixed), integer, signed, unsigned, and real.
Rational for needing the mixing is that the different types have different
sizing rules for operations and in some cases the mixing allows the number of
bit for the integer and fractional parts to be inferred. If type conversions are
used integer and real types will have to have these ranges specified to the
conversion function. Discussion followed. Resolution was to allow overloading
between real and fixed point types, but not between ufixed, sfixed, signed, and
unsigned. Also, the operation, ufixed - ufixed,produces ufixed

Side note, do we allow fixed point literals. I.E. "00100.001"

FT14 Array of unconstrained arrays of unconstrained elements.
John raised point that the unconstrained array will have a performance
impact. Some else raised the issue of the possibility of code bloat caused
by having all the different variants of a record.  John believe that this
if a function of the implementation. Some implementation may trade code
space for code speed and bloat could occur. Other implementation may
not make this trade off.

A discussion of the 'ELEMENT attribute occurred. One question was does
the 'ELEMENT attribute of records take a string for the field name or
is it just a simple identifier. Currently it is a simple identifier.
The point was raised why not just use the object.field notation.
It was pointed out that for types this notation is not defined and
there is still an issue with array types because it may not be possible
to specify a valid index. Ryan pointed out the 'ELEMENT does not
have the same restriction that 'BASE. 'BASE is currently only allowed
as a prefix to another attribute. 'BASE cannot be used as a type mark
defining a subtype or object. John will investigate why there is
this restriction.  Since 'ELEMENT doesn't have the restriction code
like
  TYPE myrecord IS RECORD
    f1 : integer;
  END RECORD;

  CONSTANT c1: myrecord'ELEMENT(f1) := 5;

  would be legal.

  FT14 is DONE and reviewed.

Meeting closed.