Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unusual code in Operator for << and >> #548

Closed
RobertBaruch opened this issue Nov 21, 2020 · 3 comments
Closed

Unusual code in Operator for << and >> #548

RobertBaruch opened this issue Nov 21, 2020 · 3 comments
Labels

Comments

@RobertBaruch
Copy link
Contributor

This didn't make sense to me:

>>> from nmigen import *
>>> s1 = Signal(4)
>>> s1.shape()
unsigned(4)
>>> s1.shift_left(2).shape()
unsigned(6)
>>> (s1 << 2).shape()
unsigned(7)

The code causing this comes from Operator:

            if self.operator == "<<":
                if b_signed:
                    extra = 2 ** (b_width - 1) - 1
                else:
                    extra = 2 ** (b_width)     - 1
                return Shape(a_width + extra, a_signed)
            if self.operator == ">>":
                if b_signed:
                    extra = 2 ** (b_width - 1)
                else:
                    extra = 0
                return Shape(a_width + extra, a_signed)

Effectively, the constness of the shift amount is not used.

Two points:

  • This works by taking into account shifting by a non-const signal.
  • __check_shamt prevents shifting by a signed Value, so b_signed will never be true.

Is it okay to put some extra code in there to handle the case where we are shifting by a Const and be a bit more surgical in the computing the new width?

@whitequark
Copy link
Member

Effectively, the constness of the shift amount is not used.

This is intentional. Basically, if we special-case x << 1, then should we special-case x << (1 + 1)? "No constant folding is ever performed when determining the shape of a value" is a nice simple answer. Constant folding is not.

  • __check_shamt prevents shifting by a signed Value, so b_signed will never be true.

That's a leftover of some very early changes. We can get rid of that.

whitequark added a commit that referenced this issue Nov 21, 2020
@whitequark
Copy link
Member

I'm curious, do you have a case where constant folding would help you? In general shape determination in nMigen is very conservative, so I'm not sure if fixing this particular instance would help a lot.

@RobertBaruch
Copy link
Contributor Author

RobertBaruch commented Nov 21, 2020

No, I just thought it was a bit odd to see that. Truncation "just works":

x = Signal(32)
y = Signal(32)

m.d.comb += y.eq(x << 5)
m.d.comb += Assert(y == (x << 5)[:32])

so it never really matters.

Clearly if I did something like:

x = Signal(32)
y = Signal(len(x << 5))

It would make a difference, but honestly I never do that and I don't see why anyone else would.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants