From 23edce1d6cbcf8a7752818481a51eda379be3932 Mon Sep 17 00:00:00 2001 From: Kenneth MacKenzie Date: Tue, 18 Jun 2024 09:12:07 +0100 Subject: [PATCH] Fix incorrect Note reference (#6217) --- plutus-core/plutus-core/src/PlutusCore/Bitwise.hs | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/plutus-core/plutus-core/src/PlutusCore/Bitwise.hs b/plutus-core/plutus-core/src/PlutusCore/Bitwise.hs index 7ffae07dbf6..4c8f0dc9324 100644 --- a/plutus-core/plutus-core/src/PlutusCore/Bitwise.hs +++ b/plutus-core/plutus-core/src/PlutusCore/Bitwise.hs @@ -600,13 +600,12 @@ replicateByte len w8 {- Note [Shift and rotation implementation] Both shifts and rotations work similarly: they effectively impose a 'write -offset' to bits in the data argument, then write those bits to the result -with this offset applied. The difference between them is in what should be -done if the resulting offset index would fall out of bounds: shifts just -discard the data (and fill whatever remains with zeroes), while rotations -'wrap around' modularly. This operation is bit parallel by definition, thus -theoretically making it amenable to the techniques described in Note [Bit -parallelism and loop sectioning]. +offset' to bits in the data argument, then write those bits to the result with +this offset applied. The difference between them is in what should be done if +the resulting offset index would fall out of bounds: shifts just discard the +data (and fill whatever remains with zeroes), while rotations 'wrap around' +modularly. This operation is bit parallel by definition, thus theoretically +making it amenable to the techniques described in Note [Loop sectioning]. However, the naive way of doing this runs into a problem: the byte ordering on Tier 1 platforms inside `Word64` means that consecutive bit indexes