-
Notifications
You must be signed in to change notification settings - Fork 24
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
[Primitives] Fix slice primitives #1139
base: master
Are you sure you want to change the base?
Conversation
leonardt
commented
Sep 14, 2022
- Promote int-like values in get_slice/set_slice
- Update doc to refer to set_index instead of set_bit
- Support set_slice of length 1 for constant values
* Promote int-like values in get_slice/set_slice * Update doc to refer to set_index instead of set_bit * Support set_slice of length 1 for constant values
Codecov Report
@@ Coverage Diff @@
## master #1139 +/- ##
==========================================
+ Coverage 85.00% 85.01% +0.01%
==========================================
Files 154 154
Lines 16368 16379 +11
==========================================
+ Hits 13914 13925 +11
Misses 2454 2454
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
@@ -249,23 +249,26 @@ Slice function interfaces: | |||
* width: constant slice width | |||
|
|||
|
|||
### set_bit | |||
### set_index |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would be in favor of renaming the function (publicly, i.e. in the docs) to set_bit
. We could deprecate set_index
for now with warning (doubt anyone is using it anyway...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was changed to set_index because the pattern is more general than just set_bit (i.e. you can use it on generic arrays, rather than just on Bits), so I think it makes more sense to keep it as set_index for generality
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. In that case, why do we need a separate function? I.e. why is it not covered by set slice with width 1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simpler to use when you know you're only interested in one index. For the same reasons in Python we have x[1]
versus having to do x[1:2]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense -- but I would argue x[1]
and x[1:2]
is the same interface with different arguments (in fact it literally is the function __getitem__
).
Maybe we don't need to do this in this change, but seems reasonable to refactor to have the following interface:
"""
* target: Array[N, T]
* value: Union[Array[M, T], T]
* start: UInt[W]
where M < N and W <= clog2(N)
"""
def set(target: Array, value: Union[Type, Array], start: UInt):
...
Now that I think about it there are few new concerns here:
- Should this function work with all
Array
s and not justBits
? I kind of assumed it did, but looking at the code closer I'm not certain. - Do we need a
width
argument? Can it just be inferred fromvalue
? Ifvalue
is an array of the same dimensionality astarget
then it is a slice set; else if it is of dimensionality one less thanvalue
then it is an index set (of course assuming the contained types match up and all). - In the case
start
being a constant value, should we optimize for the simple wiring (non-dynamic mux) case?
Moving this conversation here:
I think my note was unclear. I meant the case when |