Re: [vhdl-200x] (proposal) Extension of the RANGE syntax to provide MODULAR and

[Might have been already sent. Sorry if this is a duplicate]
 > > So the semantic of operators for these modular/saturated subtypes
 > > is the same as the semantic for the existing integer types
 > > operators.
 > So far, i'm ok. What change do you expect ?

If we need modular/saturate behaviours, we need modular
and saturate types.

 > > As a consequence, the result of 'x + y + z' may be not the
 > > same as the result of 't = x + y; t + x'.
 >
 > I suppose you intended to write 't = x + y; t + z'.
 > I don't see where you define the operands either, so i don't see your
 > point.
 > Anyway, writing such expressions leaves the door open to precedence
 > troubles. Parentheses are cheap these days, fortunately.

Let's clarify that using saturate subtype (there is a similar issue
with modular types):

   subtype sat is integer saturate -128 to 127;
   variable x, y, z, t, res : sat;
...
   x := 125;
   y := 4;
   z := -3;

   res := x + y + z; --- A
   --  The '+' designate the integer '+' binary operator, so the
   --  right hand side is 125 + 4 - 3 = 126
   --  So res = 126.

   t := x + y;  ---  B
   --  Use the integer '+' binary operator, so the right hand side
   --  is 129, saturated to 127 during assignment
   res := t + x;
   --  So res = 124


So using an intermediate variable (for style or for debugging) changes
the final result.

For me that's a no-go.

There is another no-go: the saturate doesn't work well with extreme
values:

   subtype sat is integer saturate integer'range;

   x := 12;
   x := x + 2_000_000_000; -- ok
   x := x + 1_000_000_000; -- KO: overflow during the addition.

Tristan.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.