Wolfgang,
I think I see your point. Let me explore in a bit more depth.
Regarding my first point, suppose I try to define a constrained array
type as follows:
type T is array (10_000_000_000 to 10_000_000_009) of bla;
The literals 10_000_000_000 and 10_000_000_009 are of type
universal_integer, and so are implicitly converted to INTEGER to form
the index bounds of the array type. If INTEGER is a subtype containing
just the values –2147483647 to +2147483647, then the conversion fails,
since a type conversion involves a check that the converted value is
within the subtype.
So we couldn't leave this aspect of the language as it stands. I guess
we could define a new base type, say INTEGER64, of which INTEGER is a
subtype, and change the rule about array bounds to specify an implicit
conversion to INTEGER64 instead of INTEGER. So this appears solvable.
Regarding the second point, my concern is that if we left all of the
predefined operators and functions with INTEGER parameters, then we
couldn't use them with values outside the 32-bit range. This would seem
pretty strange, so we would want to change all of these operators and
functions to have INTEGER64 parameters. The same would also apply to the
functions in the standard packages. This is conceptually a simple
change, but given the number of functions and their bodies, it's a major
effort.
Also, users with their own subprograms with INTEGER parameters would
have to decide whether to update them. If they don't, then new code that
uses the parameters would be limited to 32-bit values as actual
parameters. A potential compatibility issue here.
So in summary, I think making INTEGER a subtype of a new INTEGER64 base
type if feasible, it would be more effort than initially apparent. It
boils down to a question of priorities.
Cheers,
PA
On 11/03/2010 20:47, Wolfgang.Ecker@infineon.com wrote:
> Peter,
>
> I don't get the problem of making integer a subtype, since VHDL LRM
> states (or stated) "a Type is an subtype of its own". So value
> constraint is also imposed of a subtype and the valid assignment of an
> expression (with the special case of the literal) is not thecked at
> the expression side but at the object side, when the value is assigned.
>
> The idea of the subtype would solve the problem, that the value of the
> attribute of integer'high (and others) would not change. Further on,
> the foreign language interface would be able to handle the same size
> of objects.
>
> Kind regards,
> Wolfgang
>
>
>
> ------------------------------------------------------------------------
> *Von*: owner-vhdl-200x@eda.org <owner-vhdl-200x@eda.org>
> *An*: Jim Lewis <Jim@synthworks.com>
> *Cc*: vhdl-200x@eda.org <vhdl-200x@eda.org>
> *Gesendet*: Wed Mar 10 13:15:15 2010
> *Betreff*: Re: [Fwd: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to
> start up?]]
>
> Folks,
>
> I can see one way in which defining INTEGER to be a subtype of a
> larger base type will be problematic. The standard specifies that if
> an array is declared with an index range consisting just of literal
> integers (eg, 1 to 10), the literals are of type /universal_integer/.
> However, the values are converted to INTEGER to form the index bounds
> of the array. I would presume that /universal_integer/ would encompass
> the expanded 64-bit range, so the literals could be bigger than would
> fit in 32 bits. If INTEGER were just a 32-but subtype, this would break.
>
> Another issue is that the predefined operators and many of the
> standard functions are defined to have parameters of type INTEGER. I
> would hazard a guess that many user-defined functions and procedures
> would be defined with INTEGER parameters. The standard requires that
> the actual value be of the formal parameter's subtype. So if INTEGER
> were a 32-bit subtype, only 32-bit values would be legal for all of
> these functions.
>
> So I would suggest that, if the size of integers is extended (say, to
> 64 bits), universal_integer would grow to encompass the 64-bit range,
> INTEGER would grow to encompass the same range, and maybe we would
> define some subtypes and aliases for smaller ranges (eg, int32,
> uint32, int16, uint16, int8, uint8, byte). Not sure if going beyond 64
> bits would be a good idea, for the same reason the original VHDL-87
> standard didn't go beyond 32 bits: not efficiently implemented in a
> simulator's host instruction set.
>
> Sorry to put a dampener on an otherwise good idea.
>
> Cheers,
>
> PA
>
>
> On 27/02/2010 05:50, Jim Lewis wrote:
>> Reposting to reflector since this bounced
>>
>> -------- Original Message --------
>> Subject: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]
>> Date: Fri, 26 Feb 2010 16:13:19 +0100
>> From: Jonas Nilsson <Jonas.Nilsson@synopsys.com>
>> To: Jones, Andy D <andy.d.jones@lmco.com>, 'Jarek Kaczynski'
>>
>>
>>
>>
>> Andy wrote:
>>
>> Ø If you create a separate, longer type you have the overhead of type
>> conversions, duplicate (quadruplicate?)
>>
>>
>>
>> How about redefining INTEGER as a subtype of a new larger base type with
>> a different name?
>>
>> Ø Type conversions won’t be needed
>>
>> Ø Less compatibility issues for old code
>>
>> Ø Existing code using INTEGERS could be optimized to use 32 bits by
>> simulators/synthesis tools
>> (at least for storage, maybe not for intermediate results in expression
>> evaluations)
>>
>>
>>
>> Can you guys with more in-depth knowledge of the
>> language find any significant drawbacks with this?
>>
>>
>>
>> INTEGER‘BASE_TYPE will not be INTEGER anymore, but I don’t think
>> I’ve ever seen this attribute used with INTEGER or it’s subtypes.
>>
>>
>>
>> Regards,
>>
>> Jonas Nilsson
>>
>> Technical Staff
>>
>> Synplicity Business Group
>>
>> Synopsys, Inc.
>>
>> Kalkstensvägen 3
>>
>> SE-224 78 LUND
>>
>> SWEDEN
>>
>>
>>
>> Phone : +46-46-16 29 04
>>
>> Fax : +46-46-16 29 01
>>
>> E-mail: jonas@synopsys.com <mailto:jonas@synopsys.com>
>>
>> web : www.synopsys.com <http://www.synopsys.com> / www.synplicity.com
>> <http://www.synplicity.com>
>>
>>
>>
>>
>>
>> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On
>> Behalf Of *Jones, Andy D
>> *Sent:* Thursday, February 25, 2010 9:46 PM
>> *To:* 'Jarek Kaczynski'; 'Ray Andraka, Andraka Consulting Group, Inc'
>> *Cc:* 'Hoy, Scott - IS'; 'Jim Lewis'; 'vhdl-200x@eda.org'
>> *Subject:* RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]
>>
>>
>>
>> I don’t see how extending the minimum required range of the base integer
>> type would cause compatibility problems. The language already explicitly
>> allows it, just nobody implements it.
>>
>>
>>
>> If you create a separate, longer type you have the overhead of type
>> conversions, duplicate (quadruplicate?) operator definitions to support
>> mixing it with “standard” integer, etc. Yuck. All those different
>> integer types work in C only because C is so loosely typed.
>>
>>
>>
>> I don’t really think the simulation overhead would kill you out to
>> probably 256 bits (signed) or so, and simulation speed would hardly be
>> “crippled” considering the alternative: signed or sfixed (255 downto 0),
>> or even (31 downto 0). A 256 bit integer will still be faster than a 4
>> bit signed/sfixed.
>>
>>
>>
>> *Andy D Jones
>> *Electrical Engineering
>>
>> Lockheed Martin Missiles and Fire Control
>> Dallas TX
>>
>> Cell: 817-422-3124
>>
>>
>>
>> *From:* Jarek Kaczynski [mailto:jarekk@aldec.com]
>> *Sent:* Thursday, February 25, 2010 1:57 PM
>> *To:* Ray Andraka, Andraka Consulting Group, Inc
>> *Cc:* Jones, Andy D; Hoy, Scott - IS; Jim Lewis; vhdl-200x@eda.org
>> *Subject:* Re: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]
>>
>>
>>
>> Adding new type with higher size requirements is probably better idea
>> than changing the current definition (mainly for compatibility reasons).
>>
>> Calling the longer type 'long integer' may confuse some users due to
>> clash with C integer types:
>>
>> C integer: 16-bit or more
>>
>> C long integer: 32-bit or more
>>
>> C long long integer: 64-bit or more
>>
>> Current VHDL integer is pseudo-32-bit (due to symmetrical value range -
>> can we change it?). All simulators I have used let you extend this
>> incomplete range to the full 2's complement range if you specify
>> '-relax' switch or something similar, maybe we should sanction it...
>>
>>
>>
>> Adding new integer type with at least 64-bit value range seems
>> reasonable: all VHDL simulators must support such type internally
>> anyway, just to handle all required values of TIME type.
>>
>>
>>
>> Standardizing longer integer types may trigger resistance: if I remember
>> correctly, even on 64 MPUs there is a performance penalty while doing
>> 128-bit arithmetic operations. Simulator vendors may not want support
>> data type that cripples simulation speed.
>>
>>
>>
>> And one more remark: I'm definitely for the revival of work VHDL
>> standard update. Let's show the community that _not_ the entire world
>> revolves around SystemVerilog...
>>
>>
>>
>> Jerry Kaczynski
>>
>> On Thu, Feb 25, 2010 at 11:22 AM, Ray Andraka, Andraka Consulting Group,
>> Inc <ray@andraka.com <mailto:ray@andraka.com>> wrote:
>>
>> I also run into this issue frequently. Another possible approach would
>> be to add a long int type rather than modifying the existing integer
>> type.
>>
>>
>>
>>
>> At 02:10 PM 2/25/2010, Jones, Andy D wrote:
>>
>> The current standard requires at least 32 bit signed (well almost, the
>> most negative 32 bit signed number is not actually required!), but
>> allows vendors to support more. Almost all vendors support either the
>> minimum standard, or full 32 bit signed, and that's it. Why don't we
>> just increase the required minimum standard to 64, 128, 256, ... (?) bit
>> signed integers? Go beyond 256, and you will start to get diminished
>> simulation performance returns due to having to carry around 256+ bits
>> whether you use them or not. And simulation performance is one big
>> reason to use integers in the first place (in addition to usage
>> semantics).
>>
>> The way the fixed point package is set up almost gets you the usage
>> benefits of integers (e.g. when 0 fractional bits are used), especially
>> WRT lossless intermediate results in expressions, but it still requires
>> the manual resizing for storage. I know the issue of overloading
>> assignment operators is a hot-button issue, but in this case, where the
>> numerical interpretation of the bits is well-understood, it sure would
>> be nice to have automatic resizing (and even sfixed/ufixed conversion)
>> upon assignment (with assertions upon numerical loss, just like integers
>> have). Of course, the ufixed subtraction operator would have to promote
>> the results to sfixed (why does ufixed subtraction bump the size by one,
>> but not promote to sfixed?).
>>
>> Of course the downside (other than manual resizing and promotion to
>> signed) of the fixed point package is simulation performance, relative
>> to integers. For simulation performance, maybe a hybrid approach would
>> work? Instead of unconstrained arrays of bits, we could use
>> unconstrained arrays of integer (whatever integer will be?). Of course
>> you'd give up meta-values too, but it would be worth it for the
>> performance improvement.
>>
>> 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>
>> [mailto:owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org>] On
>> Behalf Of Hoy, Scott - IS
>> Sent: Thursday, February 25, 2010 9:30 AM
>> To: Jim Lewis; vhdl-200x@eda.org <mailto:vhdl-200x@eda.org>
>> Subject: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]
>>
>> How about a large integer/big decimal package?
>>
>> I have been bitten a few times on overflowing the range of an integer in
>> VHDL in some functions in DSP libraries I have built that can overflow
>> 32-bit integer conversions pending on settings. As an example, I have a
>> generic numerically controlled oscillator (NCO) with frequency sweep
>> control that, pending on user constraints, can trip a VHDL error due to
>> exceeding the size of the integer type. I have a work around to get by
>> this but a large integer would be very useful in this case. It would
>> also be useful to be able to create an unsigned 32-bit integer subtype
>> which is currently prohibited due to the requirements on the current
>> VHDL integer types and subtypes. This and larger integer sizes would be
>> useful in CPU modeling. This would allow VHDL to have integer data
>> types that can be identical to the size of the C/C++ integer types. I
>> would expect the user would be required to define the range of such an
>> integer and that synthesis tools should be able to synthesize it due
>> to requiring a range definition.
>>
>>
>> If VHDL currently has the ability to do this, I would like to know.
>> From the VHDL documentation I have read, the integer types are limited
>> to 32-bits for signed, 31-bits for unsigned.
>>
>> Regards,
>>
>> Scott D. Hoy
>> E-mail: scott.hoy@itt.com <mailto:scott.hoy@itt.com>
>> Phone: 301-497-9900 Ext. 7162
>> Fax: 301-497-0207
>>
>> ITT-AES
>> 141 National Business Pkwy. Suite 200
>> Annapolis Junction, MD 20701
>> Phone: 301-497-9900 Fax: 301-497-0207
>>
>> -----Original Message-----
>> From: owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org>
>> [mailto:owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org>] On
>> Behalf Of Jim Lewis
>> Sent: Tuesday, February 23, 2010 10:13 AM
>> To: vhdl-200x@eda.org <mailto:vhdl-200x@eda.org>
>> Subject: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]
>>
>>
>>
>> -------- Original Message --------
>> Subject: [Accellera:vhdl] Time to start up?
>> Date: Mon, 22 Feb 2010 09:18:24 -0600
>> From: Lance Thompson <lancet@us.ibm.com <mailto:lancet@us.ibm.com>>
>> To: vhdl <vhdl@lists.accellera.org
>> <mailto:vhdl@lists.accellera.org>>
>>
>>
>>
>>
>> Hi everyone,
>>
>> In the immortal words of Roger Waters of Pink Floyd fame, "Is there
>> anybody out there?"
>>
>> It's been a while since we released revision of VHDL to the IEEE and
>> took it through the ballot process to come out with 1076-2009. If my
>> memory is correct, we released it the IEEE early in 2008 and the IEEE
>> finished the ballot process at the end of 2008 or very early in 2009.
>> At that point, I imagine everyone took a well deserved break from the
>> VHDL standardization activity. I know I did :-)
>>
>> Since it's been around 2 years since we worked on details of the
>> language, I started to wonder if we should warm up the group and start
>> to drive any new changes to the language.
>>
>> Any ideas?
>>
>> Lance Thompson
>> IBM Technology Development
>> e-mail: lancet@us.ibm.com <mailto:lancet@us.ibm.com>
>> office: 507.253.0145
>> mobile: 507.261.3607
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Jim Lewis
>> Director of Training mailto:Jim@SynthWorks.com
>> <mailto:Jim@SynthWorks.com>
>> SynthWorks Design Inc. http://www.SynthWorks.com
>> 1-503-590-4787
>>
>> Expert VHDL Training for Hardware Design and Verification
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> --
>> This message has been scanned for viruses and dangerous content by
>> MailScanner, and is believed to be clean.
>>
>>
>> This e-mail and any files transmitted with it may be proprietary and are
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this e-mail in error please notify the
>> sender.
>> Please note that any views or opinions presented in this e-mail are
>> solely those of the author and do not necessarily represent those of ITT
>> Corporation. The recipient should check this e-mail and any attachments
>> for the presence of viruses. ITT accepts no liability for any damage
>> caused by any virus transmitted by this e-mail.
>>
>> --
>> 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.
>>
>>
>>
>> --Ray Andraka, P.E.
>> President, the Andraka Consulting Group, Inc.
>> 401/884-7930 Fax 401/884-7950
>> email ray@andraka.com <mailto:ray@andraka.com>
>> http://www.andraka.com
>>
>> "They that give up essential liberty to obtain a little
>> temporary safety deserve neither liberty nor safety."
>> -Benjamin Franklin, 1759
>>
>>
>>
>>
>
> --
> Dr. Peter J. Ashendenpeter@ashenden.com.au
> Ashenden Designs Pty. Ltd.www.ashenden.com.au
> PO Box 640 Phone: +61 8 7127 0078
> Stirling, SA 5152 Mobile: +61 414 70 9106
> Australia
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
-- Dr. Peter J. Ashenden peter@ashenden.com.au Ashenden Designs Pty. Ltd. www.ashenden.com.au PO Box 640 Phone: +61 8 7127 0078 Stirling, SA 5152 Mobile: +61 414 70 9106 Australia -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Mar 11 03:43:57 2010
This archive was generated by hypermail 2.1.8 : Thu Mar 11 2010 - 03:46:36 PST