Re: [myhdl-list] intbv return types and a fixed-point Object

[Jan D. <ja...@ja...>]

Felton Christopher wrote:

>>
> 
> In my experience if you have a type (object) and some operations are  
> performed the result is the same type.

I agree with that. However, in my mind, intbv is a subtype of int,
in which case this would be acceptable.

It is true that technically, intbv is *not* implemented as a subclass
of int. The reason why this couldn't be done is that it turns out to be
impossible to derive a mutable type (like intbv) from an immutable type
(like int). But that's a pity, it would have simplified many things.

> Also, I think it would simply  
> matters some what for users (but could cause other issues) not having  
> to use the [:].  There could be more negatives than positives to such  
> a change.

I assume you refer to the requirement to assign to intbv instances as follows:

a[:] = b

to change their value.

This is *not* related to the return type of intbv operations. It would
still be necessary when the return type is changed.

The reason is that when you would use plain name assignment:

a = b

the original intbv object is gone, including its constraints. So in
simulation, you lose run-time bound checking, and conversion would
become close to impossible. I think it's a small price to pay
for these features.

I'm thinking about adding a "val" property to intbv though so you
could do:

a.val = b

Perhaps this makes more sense when you're not thinking about the
bit representation.


> I imagine it might be difficult to change at this point because it  
> could affect much of the user code.  Also, don't know if it would have  
> any implications on conversion, checking, etc.

No, I think it would be straighforward. I expect that everything that
works now would continue working, except that you could do some
additional things. In particular, you could index and slice an
arithmetic expression.

The only price would be simulation performance hit. The question is
whether this is worthwhile for a feature that is seldom (?) used.
Someone would have to analyze this in detail to make a good
decision. Perhaps the performance hit is irrelevant - I don't know.

Jan


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com