in reply to Modifying multiple bits in a byte - bitwise operators

Thank you very much for the replies all. I tested them all out and am still confused about certain things, so I will definitely be doing some major reading/testing this week. I've posted this here just for completeness.

What I did find out is that I can unset all bits at a certain location by doing a negate AND using the total value of the bits I want to unset. For example, if I want to unset bits 4-3:

my $x = 0xFF;

# 0x18 == 24, the max value of both bits
# 4-3 set

printf("%b\n", &= ~0x18);

__END__

11100111

[download]

Then, I can re-set those bits by ORing the bit string with any value within the value range of those two bytes:

$x |= 0x14; # 20;

__END__

11110111

[download]

Here's my first working sample of real-world code that I've put together. I'm certain it isn't the most concise, efficient or elegant code, but it'll get better as I learn about how all the bitwise operators work. In my case, I'm dealing with a 16-bit wide configuration register that are stored as two bytes, but when working on them, I merge them together so the code more closely represents what the hardware's datasheet specifies as bit locations:

sub queue {
    my ($self, $q) = @_;

    if (defined $q){
        if (! exists $queue{$q}){
            die "queue param requires a binary string.\n";
        }
        $self->{queue} = $queue{$q};
    }

    $self->{queue} = DEFAULT_QUEUE if ! defined $self->{queue};

    my $bits = $self->bits;

    # unset
    $bits &= ~MAX_QUEUE;

    # set
    $bits |= $self->{queue};

    my $lsb = $bits & 0xFF;
    my $msb = $bits >> 8;

    $self->register($msb, $lsb);

    return $self->{queue};
}

[download]

Replies are listed 'Best First'.
Re^2: Modifying multiple bits in a byte - bitwise operators
by Marshall (Canon) on Jan 11, 2017 at 01:05 UTC
    Hi stevieb!

    Yes, the generic set of HLL operations to set a field of bits is to do a bit-wise AND with a one's complement of a "mask" to make sure the bits are all unset, then do a bit-wise OR operation to set those bits to however you want them.

    The difference between the HLL version and an actual Assembly language implementation is that there is some uncertainty in how big a "natural integer" is with the HLL. With assembly, I know exactly whether I've got 8, 16, 32, or 64 bits. Typically with HLL, you only know something like size >= 32 bits for an int.

    So, with ASM, the "negate the MASK" step would not be there. The ~MASK value would have been compiled in as a "load immediate" constant. With HLL, we want to actually calculate this "flipping of bits" mask. When we calculate ~0x3, we get 2 bits of zeroes and as as many leading one bits as needed to make up the "native int". Design for a min size int, but allow bigger ints.

    Here is some code with a couple of things I like to do: 

    use strict;
use warnings;

use constant {UP    => 0x0<<3, 
              DOWN  => 0x1<<3, 
              LEFT  => 0x3<<3, 
              RIGHT => 0x2<<3, 
              MASK  => 0x3<<3};


printf "direction Mask: ";
print8bits (MASK);  #Prints: direction Mask: 0001 1000 

my $register8b=0;

#set direction left
$register8b = $register8b & ~MASK | LEFT;
print8bits ($register8b); #Prints: 0001 1000 

#set direction down
$register8b = $register8b & ~MASK | DOWN;
print8bits ($register8b);  #Prints: 0000 1000 


sub print8bits
{
   my $int = shift;
  
   print map{s/(\d{4})/$1 /g;$_;}sprintf "%08b\n", $int;
}

    [download]
    1. Consider the use of the constant feature. Make a constant block for each of the fields in the 16 bit register. Naming convention to your satisfation. Maybe DIRECT_UP or DIRECTION_UP instead of just UP or whatever. Consider the naming convention in whatever documentation that you are working from.
    2. I prefer "0x3" notation over just decimal 3 for these things. Although they code to exactly the same bits, use of 0x notation alerts me to the fact that this is some hardware bit thing and not a "normal" variable.
    3. For debugging, I find something like my sub print8bits() to be useful. Space the bits out into 4 bit hex compatible groups. The %b format spec in Perl is very nice (doesn't exist in std C.. have to "roll your own").
    4. Consider a naming convention to indicate how many of the bits are "significant". $register8bit , $r8bit_control or whatever. Design the code that it will still work with native int sizes greater than what current platform is.
    5. While manipulating the 16 or 8 bit register, I just keep the internal representation as a native int, whatever that size is, rather than splitting this into say $lsB and $msB like you did. Or mucking around prematurely with pack/unpack. BTW, your code could confuse a hardware guy. Use lower case "b" for bit and upper case "B" for byte, e.g. $msB instead of $msb.
    6. If you do a lot of bit twiddling, you will find that the inability to access the hardware carry bit is a real hassle. There are various techniques around that, but not in the scope of this post.
    Hope this helps.
    I have written most of my bit fiddling code in C as I am emulating say a hardware ECC algorithm or whatever and sometimes "fast" is important. But Perl can do bit manipulation amazingly well and I have used Perl to decode some complex binary formats.
[reply]
[d/l]

      This is a great breakdown and explanation. Thanks Marshall!

[reply]

In Section Seekers of Perl Wisdom