Is there any particular reason why adding or subtracting intbv
s return int
s, but anding, shifting etc return intvb
s?
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.
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.
Here is the thread (I believe) and the rational:
https://sourceforge.net/p/myhdl/mailman/message/22137406/
(gmane is down?)
@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?
@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.
That’s good to know. It seems like an arbitrary choice made for performance reasons. Perhaps we should document it?