RE: [vhdl-200x] Modular types

Can someone help me understand why the modulus affects the definition of logical and shift operations?  I imagine logical and shift operations applying to the twos-complement representation of the integer.  I don't see how the modulus affects this definition.

Also, I've seen Galois fields pop up a few times in relation to logical/shifting operations, but I don't think they're relevant.  Sure, simple integer wrap-around behavior defines a field for a prime modulus, but it isn't fancy enough for extension fields (binary or otherwise).  In other words, shifting only corresponds to multiplication and division when the modulus is *not* active (i.e. when it's equivalent to normal integer arithmetic), and good implementations of GF arithmetic use Zech logarithms for small fields, anyway.   

- Ryan

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of tgingold@free.fr
Sent: Friday, July 11, 2014 10:41 AM
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Modular types

> But if we are providing boolean and shift operators for the special 
> case of modulo 2**n, then we have to do one of:
> 
> 1) restrict modular types to mod 2**n. Prohibits other legitimate 
> uses.
> IMO : Just No.

Why not.

> 2) Define boolean and shift only for mod 2**n and prohibit for other 
> cases. Ugly irregular language feature. IMO : No.

That's my preferred choice.  There is no obvious definition of logicals and shift operators for not mod 2**n types.  So I suppose nobody would use them (and we could revisit this issue at a later revision).

We have many irregular rules (shift operators are only predefined for one-dimensional array of BIT and BOOLEAN); and I fear that any definition of shift and logical operator for no mod 2**n would be ugly.

> 3) Define boolean and shift only for mod 2**n and leave their 
> semantics undefined for other cases. IMO : that would not be 
> appropriate in Ada.

I agree.

> 4) Have well defined semantics for all cases, in such a way that 
> efficiency and implementation burden are tolerable, and that the 
> common 2**n case has the desired properties. IMO : this is the only 
> tolerable option of the first four.

Why not, but which one ?  And how useful it would be.

> 5) Split modular types into two  : power of two, and other. IMO : too 
> much complexity

We could split modular types into two using the same syntax (enumerated types are also split into two: characters ones and the others).
No complexity here.

Strongly in favour of 2) after the Ada experience.

Regards,
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.