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

hi !

Le 2014-10-23 19:01, tgingold@free.fr a écrit :
>> So would the syntax for part B be something like:
>> 
>> subtype integer4 is integer range 0 to 3
>> subtype modular4 is integer modular 0 to 3
>> 
>> Where integer4 would trap on overflow and modular4 would wrap?
> 
> This notation doesn't make sense.  A subtype declaration does not
> declare a type and therefore does not declare operations.  So
> the operator for integer4 or modular4 are the operators of integer.

Right. However the subtype also declares attributes to that number.
These attributes are used after operations (before assignation)
to check that the result is within the desired range.
If not, instead of trapping, it performs the modulo reduction
(hopefully using a AND mask when the "power of 2" attribute is set).

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.
So it does what you tell it to do, because you use a particular
mathematic notation that has a different meaning here.
VHDL is not mapple or matlab ;-)

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. So unless VHDL is totally changed,
there is no way to tell that the + operator is influenced by the mod
that follows it (which would override the type of the variable that
gets assigned, by the way). There are optimising compilers that can 
infer this stuff
but they must follow the language's semantic...

How would you tell the compiler to treat intermediary values as
a certain type ? Your example provides immediate integer values instead 
of subtyped
variables so it is my understanding that the compiler applies the 
default rule :
"I see integer operands, so it must be an integer operator".

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.

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.

a <= b - c; Same as above, change signs carefully.

a <= b + 1;

i4 + integer : it's a bit like a mixed base here. We can treat the
"integer=1" as a temporary modular with 'high=1, then apply the above
overflow check.

c <= b + d;
e <= b + d;

i4 + I6 : Mixed base, same as above.

I have not implemented a VHDL compiler/simulator/synthesiser so it's 
only
wild guesses (and each software certainly uses a different method).
I can only suspect how the range system is working.

I know I have only covered addition here... but that creates a lot of 
interesting questions.
Other corner cases are welcome :-)

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 ?

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.


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 ;-)


> Tristan.
yg

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