Date: Mon Sep 01 2014 - 01:15:05 PDT
Hi, Darren and Hannes, both of you are definitely right, as far as the specific Specman's implementation is concerned, where scalars of more than 32 bits have performance overhead. That's exactly the reason we're going to add all those methods to Specman. The reason for my doubt about the need to add them all to the standard is: aren't those "implementation specifics" ? For example, what if "in general" some e compiler (or maybe even Specman in future) uses "long long" scalars up to 64 bits, rather than 32-bits? They might become irrelevant, or need some variation. Again, from the purely functional perspective those methods don't really add something. The result of "my_set.min_is_uint()" is exactly the same as the result of "my_set.min()>=0 and my_set.min()<=MAX_UINT" (but the latter has performance overhead because it creates an unbounded integer), and so on. Yuri. From: Hannes Froehlich Sent: Monday, September 01, 2014 10:37 To: darren.galpin@infineon.com; Yuri Tsoglin; ieee1647@eda.org Subject: RE: some points about the new 'set' type Those methods are useful for users, writing save and well performing code. I'd be inclined to add them. -hannes From: owner-ieee1647@eda.org [mailto:owner-ieee1647@eda.org] On Behalf Of darren.galpin@infineon.com Sent: 01 September 2014 08:14 To: Yuri Tsoglin; ieee1647@eda.org Subject: RE: some points about the new 'set' type I think this could go either way.... As an example , in section 29.9, set_config() is defined in the standard and could equally be considered implementation specific. It would seem to me that the methods which return a bool add something, as they are not there within the first set. Additionally, a lot of things in Specman are implicitly 32 bit, so knowing that you are not exceeding this would be of value, as you wouldn't necessarily get an error if you did exceed it (hence why having an event through a port which is connecting to a signal > uint in bit width can end up needing multiple events to handle), so I can see the use in having them. What do others think? Cheers, Darren From: owner-ieee1647@eda.org<mailto:owner-ieee1647@eda.org> [mailto:owner-ieee1647@eda.org] On Behalf Of Yuri Tsoglin Sent: Sunday, August 31, 2014 3:04 PM To: ieee1647@eda.org<mailto:ieee1647@eda.org> Subject: some points about the new 'set' type Hi all, This is with regard to Mantis issue 4124 (adding the new 'set' type). The following pseudo-methods: set.size(): uint(bits:*) - returns the number of elements in the set set.min(): uint(bits:*) - returns the maximum value in the set set.max(): uint(bits:*) - returns the minimum value in the set seem logically justified, and clearly need to be added to the standard. Because of performance concerns, caused by the creation of an unbounded integer result, additional pseudo-methods are considered: set.uint_size(): uint set.size_is_uint(): bool set.uint_min(): uint set.int_min(): int set.min_is_uint(): bool set.min_is_int(): bool (and similar for 'max') In cases when it is known, or desired to be checked, that the actual size/max/min of a set is small enough to fit in the bounds of int/uint, these methods can be used instead of the above ones, which would avoid a creation of int(bits:*) values. However, I am in some doubt whether these additional pseudo-methods should be added to the standard as well, and whether these performance concerns (and the fact that unbounded integers have performance overhead vs. 32-bit values) are not considered implementation- (or tool-) specific. From the purely logical and functionality/semantics point of view (disregarding performance), these methods may seem an unneeded overkill. Please express your opinions on this matter. Thanks, Yuri. [cid:image002.jpg@01CFC5D4.5CC337B0] Yuri Tsoglin | e Language team, Specman RnD P: 972.3.9004305 M: 972.54.6468177 F: 972.3.9004001 www.cadence.com<http://www.cadence.com> -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
