From: <ryan.w.hinton@L-3com.com>

Date: Mon Jul 14 2014 - 11:35:38 PDT

Date: Mon Jul 14 2014 - 11:35:38 PDT

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.Received on Mon Jul 14 11:36:03 2014

*
This archive was generated by hypermail 2.1.8
: Mon Jul 14 2014 - 11:36:39 PDT
*