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

BZHI panic at wrong bit_position #13

Open
phuclv90 opened this issue Oct 21, 2020 · 0 comments
Open

BZHI panic at wrong bit_position #13

phuclv90 opened this issue Oct 21, 2020 · 0 comments

Comments

@phuclv90
Copy link

As mentioned in rust-lang/stdarch#932 the panic position for BZHI is wrong. According to the doc it'll panic when

If bit_position >= bit_size() and -C debug-assertions=1.

However the behavior is actually defined for all bit_position <= 0xFF because in the instruction the INDEX (i.e bit_position) value is the low 8 bits of the 2nd source and "The INDEX value is saturated at the value of OperandSize -1" which means for INDEX >= OperandSize the destination register is unchanged. It's confirmed by the operation:

N ← SRC2[7:0]
DEST ← SRC1
IF (N < OperandSize)
    DEST[OperandSize-1:N] ← 0
FI
IF (N > OperandSize - 1)
    CF ← 1
ELSE
    CF ← 0
FI

As you can see, if N >= OperandSize nothing in the destination register is touched and there are no undefined states except for the AF and PF flags. The Chromium test suite also actually tests those large N values such as 64 or 257 The bit_position == bit_size() case is actually very useful to create a mask with N least significant bits set with N in [0, 64] range

So I think the behavior should be changed to panic if bit_position > 0xFF or if bit_position > bit_size() so it won't panic for the bit_position == bit_size() case

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

No branches or pull requests

1 participant