Re: [vhdl-200x] A compromise about modular type, boolean operations, integers...

> I see your other post about mysig <= (3 + 2) mod 3;
> Then you complain about that it does not "mean the same thing" as
> in a mathematical declaration/syntax.
> 
> My proposition also does not declare new operators, it's right.
> However, as a VHDL expression, your example does not define the type
> of the + operator.

Sorry, but that's plain wrong.  In that example, the '+' and the 'mod'
are those from the type of mysig, so integer. That's specified by
the VHDL language.  If you want to clarify that, use that example:
  mysig <= 3;
  wait for 0 ns;
  mysig <= (mysig + 2) mod 3;

> Compilers (as I believe you know already, and VHDL is quite explicit
> about it) determine the type of operation from the operands, and not
> from the type that gets assigned.

Sorry, but that's not correct.  See the LRM section about 'context of
overload resolution'

> Let's continue in this direction and imagine other cases and the
> expected behaviours :
> 
> subtype i4 is integer range 0 to 3;
> subtype i6 is integer range 0 to 5; -- let's mix bases for more fun.
> variable a, b, c : i4;
> variable d, e : i6;
> 
> a <= b + c;
> 
> Here we have i4 + i4. As long as the + integer operator does not
> overflow, the result can be correctly reduced to mod4 during assignation.

Sorry, but not.  The above code is valid VHDL, and will produce an error
during simulation if overflow occurs.  I don't think we want to change the
semantic of existing VHDL design.

> If the range is marked as "power of two", just mask the LSB out with
> 'high.
> Otherwise, overflow can be tested quite easily
> (carry bit of the CPU, or checking if b'high + c'high > integer'high)
> and the result can be pre-adjusted (subtract 1+min(b'high, c'high) ?)
> to return in the integer range before modulo reduction and
> assignation.

But you don't always know at analysis time if the high bound is a
power of 2. So the code may be much complex than what you describe.

> And yes I try to avoid creating a whole collection of new operators,
> not for just
> the speed of execution but also the ease of coding and adoption, by
> keeping the
> implementation efforts as low as possible.
> Why define new operators when a smaller code can perform the same ?

Because it doesn't perform the same.  Having a modular semantic for
each operation is different that having a modular semantic for
assignment.

Stated with subtypes, this proposal is doomed to fail.

What you can currently do with VHDL is to declare a package that declares
a type, override all operations so that they have a modular semantic.
That would work, all will work today.

The issue is that the implementation is not easy at all (unless you want
to consider very small modulus).  And I am sure we need 2**32 modulus.

> Anyway, unless otherwise specified :
> To prevent any ambiguity, cast all temporary results to the correct
> subtype,
> by assigning the results to variables of the correct (sub)type.
> Otherwise the computer can't know what is expected of him.

If you must not have intermediate values for your proposal, I suppose
this is a no-go.  VHDL isn't a good language to define local variables.

> Oh and I just now realise : just a tiny little more effort and we can
> also provide
> saturated integers this way. Let's add this to my proposition ;-)

Again, saturating at assignment is different from saturating at
each operation.

Tristan.

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