Thanks Tristan, I'll add your comments to the Twiki page. Should I put your name in the Opposers list (yet? :) Just one note on the range of integers - the proposal is that the standard now *does* define the range of an integer. In past discussions we have rejected changing the range of INTEGER as too much past code may be (non-portably, but still...) dependent on it. Thanks, Martin -----Original Message----- From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of tgingold@free.fr Sent: 22 October 2014 09:15 To: vhdl-200x@eda.org Subject: {Spam?} Re: [vhdl-200x] More operators for integers Hello, > Also, I had intended to note that the LRM should make sure that the > range of an integer is the full 32 bits (so "not integer'high" can > still be assigned to an integer. > > Maybe we should also require that natural is a full +ve range 32-bit > int rather than a subrange... I think we are approaching the point where this proposal raises a lot of issues. The range of integers types (including the type INTEGER) is not specified by the standard. The standard simply says the range should be large enough to contain the subtype range. So consider a integer type declaration: type int7 is range 0 to 7; The implementation may choose to use a 8 bit or a 16 bit or a 32 bit type for int7. So the result of: not int7'(3) would be implementation dependent. Arg, this is not a good idea. Maybe you may propose to restrict the use of logical operators only to the type STD.STANDARD.INTEGER. First, that would be weird, and second that won't be more portable. The standard doesn't prevent INTEGER to be a 64bit types. Given the above reasons, I think it wouldn't wise to add logical operators to integer types (even the C language makes this operation implementation defined in many cases). If you want logical operators, it should be on modular power of 2 types. 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 Wed Oct 22 01:24:56 2014
This archive was generated by hypermail 2.1.8 : Wed Oct 22 2014 - 01:25:18 PDT