RE: {Spam?} Re: EXTERNAL: [vhdl-200x] A compromise about modular type, boolean operations, integers...

Tristan,

How you evaluate an expression is based on precedence. My proposal performs the subtype's modulo operation last (only on assignment), yours elsewhere/everywhere(?), based on how you described the intended result. Neither is more or less correct than the other.

What do we want? A subtype that is interoperable with its base type and subtypes thereof?

Or do we want types for which we have to redefine the operators for every combination of operand and return types we want to support? What happens when you want to add a modulo 3 type to a modulo 4 type? What is the modulo of the sum?

In your example, how would you propose communicating to the "+" operator that it is supposed to produce a modulo 4 result, given two integer literals?

For subtypes, how would you communicate the expected subtype for the return value? Be careful, this gets Verilogish (and NOT backward compatible with VHDL) very quickly!

My solution is to not communicate the operand or return subtype to the operators at all, but that they always operate on, and return, the base type, same as they always have in VHDL, and perform the modulus on assignment, the same place bounds checking for subtypes has always been. 

Simply replacing bounds-checking behavior with modulo-wrapping behavior only makes sense if both are performed the same way, at the same place.

One way to do that is with resolved subtypes, and another way is to define "special" subtypes (modulo instead of range).  A special, language-defined subtype can only do one thing. A resolved subtype, with user-defined resolution functions, suitably extended to variables, can do MUCH more.


Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX






-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of tgingold@free.fr
Sent: Thursday, October 23, 2014 12:08 PM
To: vhdl-200x@eda.org
Subject: Re: {Spam?} Re: EXTERNAL: [vhdl-200x] A compromise about modular type, boolean operations, integers...

> subtype mod4 is modular4 integer;
> 	
> signal mysig : mod4;
> 
> mysig <= 5; -- takes the value (5 mod 4) = 1

So your solution doesn't provide the modular semantic.  The problem is that it looks to work only for small modulus values, and fail completely for non-trivial operations.

For example: mysig <= (3 + 2) mod 3;

If the type of mysig was really a modular of 4 type, mysig would be assigned to 1 (the result of 3 + 2 is 1, and 1 mod 3 is 1).
With your resolved type, mysig is assigned to 2 (the result of 3 + 2 is 5, and 5 mod 3 is 2).

So no, your solution doesn't work.  If you want a modular type, you need operator with the modular semantic.

Tristan.

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



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