Overloaded Assignments

Proposal Details

• Who Updates: AndyJones
• Date Proposed: 2013-05-03
• Date Last Updated:
• Priority:
• Complexity:
• Focus: General Language

Current Situation

Currently, an explicit conversion/resizing function and/or range specification is required when assigning an object from an expression of differing type or size.

Requirement

Allow overloading assignment statements to provide type conversion and resizing.

Implementation Details

Treat the assignment tokens ( <= and := ) as infix notation procedure calls, which could be overloaded by present means.

Retain existing compiler knowledge of LHS type and size when resolving LHS anonymous literal expressions, "others", etc.

Use Cases

While applicable to a wide range of situations, arithmetic on vector-based types (e.g. signed/unsigned or sfixed/ufixed) is the most commonly used beneficiary of this change.

First, VHDL's handling of integer arithmetic can be taken as an example. Expressions of integer types and subtypes always evaluate to the full range of integer (e.g. signed 32 bit). Smaller range interpretations of integer results occurs upon assignment to an object of an integer subtype. Then an error is asserted if the results do not comply with the receiving object's range.

Fixed point arithmetic uses a similar approach, but not as fully capable. Fixed point operators return results large enough in size to handle the largest possible result based on the argument sizes (excepting division). However, fixed point operators never return results of different signedness than the argument(s), and mixed-signdness arguments are not allowed. Thus ufixed subtraction must always return ufixed results, even though the numerically accurate result may have been negative.

A more integer-like use model could be provided if fixed point operators were defined for mixed-signedness arguments, and always returned sfixed. Then assignment overloading could be used to automatically convert the result to the signedness of the receiving object, resize to fit and assert warnings if not numerically accurate (e.g. truncating a signed to an unsigned, overflowing a smaller object numerical range, etc.

Working in fixed point with the above capabilities provides seamless integer, fraction, signed and unsigned arithmetic on arbitrarily sized quantities.

Implementing these capabilities could be accomplished a couple of ways:

1. Continue using the existing types ufixed and sfixed:

   1. Move the existing sfixed/ufixed type declarations to fixed_float_types.

   2. Alias the sfixed/ufixed types in fixed_pkg and fixed_generic_pkg for backward compatibility.

   3. Add a new package, e.g. universal_fixed_generic_pkg, containing:

      1. Aliases of the sfixed/ufixed types

      2. Aliases of existing subprograms from fixed_generic_pkg

      3. Implementations of mixed_signedness functions

      4. Implementations of overloaded assignment procedures

2. Create a new package with new type names and subprograms

Arguments FOR

1. Overloadable assignments allows lots of possibilities not related to a new fixed point arithmetic capability
   1. Can be used to address assigning sfixed/ufixed to an object of different range (currently silent & wrong)
2. Allows integer-like arithmetic of arbitrary size (not needed if arbitrary-length integers are adopted)
3. Allows integer-like arithmetic on fixed point quantities.
4. Obviates the need to provide target-sized results from functions, and problems therein (verilog).

Arguments AGAINST

1. Major language change with potentially undesirable results. (AJ)

General Comments

-- KevinJennings - 2013-05-09

- How does a compiler 'know' that it one type is really a subtype of the other? In particular, sfixed and ufixed are both currently defined as full types whereas positive, natural etc. are both subtypes of integer which then provides a mechanism to perform operations at full blown precision (for good or bad) as Andy describes. Unless sfixed/ufixed are special cased in the language (which would likely not be considered a 'good' approach), it's not clear what mechanism would be used to cause the automatic conversion of ufixed to sfixed to do the math.

- Perhaps if ufixed was redefined to be a subtype of sfixed just like natural is a subtype of integer then that would be the mechanism needed to perform any math as type sfixed with the conversion only happening during the assignment as suggested.

- If subtyping is not really feasible, then how would some other newly defined type be able to take advantage of this feature? In other words, is the only way to get this automatic conversion to a larger type possible by adding a special case to the language?

- The statement 'Thus ufixed subtraction must always return ufixed results, even though the numerically accurate result may have been negative.' is not really true. If a designer is subtracting two ufixed and storing it to a ufixed then the intention could also be that the result is meant to roll over, not to be negative (It could also be a design error). My point is simply that the 'numerically accurate' result might not be negative if the intention is to have the result wrap which then pokes a hole in the one use case presented. Given that there are two valid interpretations of what the result of subtracting two ufixeds 'should' be, the language change being presented is only because the 'default' interpretation is not what some users would like.

- I agree that there may be 'potentially undesirable results' with this, and I don't think the use case presented was very compelling basically for the reason mentioned in the previous bullet so from that perspective I wouldn't support this change. However, I think that there are also may be some use cases that would require this change that would be compelling, so I think some more thought should be put into describing those use cases here to see if they hold water.

Supporters

Add your signature here to indicate your support for the proposal