As Andy notes, the code optimization steps of a compiler can be quite useful.

When the target variable is max 8 bits large, many compilers can detect that the final "a & 0xff" will not have any bits to mask away, so the compiler can strip out this step without changing the behaviour. The source code does a compatibility step that need not result in corresponding native instructions.

And many compilers are smart enough to notice that a shift of n*8 bits represents a full byte shift. They may then look at their available addressing modes to figure out if they can pick up a byte in the middle instead of loading the larger word and shifting.

On 32-bit compilers, it isn't uncommon that the compiler looks at code and detects four byte writes that are shifted and ored together and detects that the code represents a big-endian or little-endian load (or store) and replaces a lot of shifts and oring with either a single 32-bit native read or a 32-bit native read followed by a built-in byte swap. Or possibly a single "read 32-bit swapped" instruction.

It is very easy to look at source code and consider shifts and masking to be big, ugly and expensive. But since it is "the" portable way to handle the operations, many compilers looks for this kind of code and translates it to the optimum native code.