Intbv arithmetic operations return types

#1

Is there any particular reason why adding or subtracting intbvs return ints, but anding, shifting etc return intvbs?

#2

The reason could be that adding and subtracting (and alike) are arithmetic operations, where anding, shifting e.a. are bitwise logical operations.
But in all cases the result of the operation is used in an assignment and thus the actual integer value will be used. Making the promotion of the integer result of the bitwise logical operations to intbv superfluous.

#3

There is an old thread, on the old mailing-list, discussing this topic. I had tested returning intbv in all cases, it had a performance impact - at that time it was decided not to use intbv in all cases. I don’t recall the arguments for and / or against, just that in the past it was proposed to use intbv as all returns and it was, at that point in time, decided against.

#4

http://old.myhdl.org/doku.php/user:cfelton:projects:small_profile ???

#5

Here is the thread (I believe) and the rational:
https://sourceforge.net/p/myhdl/mailman/message/22137406/

(gmane is down?)

#6

@cfelton Thanks for enlightening me (us?), I didn’t think of slicing of/indexing the result. But then we should never make a distinction between arithmetic and logical operators?

#7

@cfelton I ran into the case this morning …

movingxpattern[i].next = ((xcounter.Q << SHIFT_PIX) + ycounter.Q + i)[WIDTH_PIXEL:]

throws an exception: AttributeError: ‘Subscript’ object has no attribute ‘vhd’, obviously because I’m trying to slice an integer. The work-around:

movingxpattern[i].next = ((xcounter.Q << SHIFT_PIX) + ycounter.Q + i) & (2 ** WIDTH_PIXEL - 1)

is fine.

#8

That’s good to know. It seems like an arbitrary choice made for performance reasons. Perhaps we should document it?