user8033: I stumbled upon this piece in digitalWrite.
I'm unsure why clearing interrupts and setting/resetting SREG is neccesary here.
Can anyone shed a light on this?
uint8_t oldSREG = SREG;
cli();

if (val == LOW) {
    *out &= ~bit;
} else {
    *out |= bit;
}

SREG = oldSREG;

I figure they don't want an interrupt to possibly change any of the bits in the output register while it executes *out = *out & ~bit?
And what would the SREG have to do with it? Could the code affect SREG and why would that matter?
When speed matters, I often use the direct port manipulation, I'd like to get an idea if it's neccesary for me to include these "precautions".

user7508: Answering only the last question, as the rest has been addressed by
Majenko.

I often use the direct port manipulation, I'd like to get an idea if
   it's neccesary for me to include these "precautions".

If you use constant values, like PORTB |= _BV(2); or the like, there
is no need, since this compiles into a single CPU instruction. Even if
you write things that take multiple instructions,
like PORTB |= _BV(2) | _BV(3);, you probably know whether you are
modifying the same register inside an interrupt handler or not. If not,
no need for critical section either. The authors of the Arduino core
cannot make any assumptions.

user4143: 
I figure they don't want an interrupt to possibly change any of the bits in the output register while it executes *out = *out & ~bit?

Correct. That is known as a critical section.

And what would the SREG have to do with it? Could the code affect SREG and why would that matter?

SREG is where the flag that says if interrupts are enable or not is stored.  Basically that is storing the current state, disabling interrupts, then restoring the current state.
The upshot is:

If interrupts are enabled to begin with, they are disabled, then re-enabled.
If interrupts are disabled to begin with, they are again disabled, and they remain disabled.

It's a way of restoring the previous state without actually having to check what the state was and set or clear accordingly.

8033: <p>I stumbled upon this piece in <code>digitalWrite</code>.
I'm unsure why clearing interrupts and setting/resetting SREG is neccesary here.</p>

<p>Can anyone shed a light on this?</p>

<pre><code>uint8_t oldSREG = SREG;
cli();

if (val == LOW) {
    *out &amp;= ~bit;
} else {
    *out |= bit;
}

SREG = oldSREG;
</code></pre>

<p>I figure they don't want an interrupt to possibly change any of the bits in the output register while it executes <code>*out = *out &amp; ~bit</code>?</p>

<p>And what would the SREG have to do with it? Could the code affect SREG and why would that matter?</p>

<p>When speed matters, I often use the direct port manipulation, I'd like to get an idea if it's neccesary for me to include these "precautions".</p>
 7508: <p>Answering only the last question, as the rest has been addressed by
Majenko.</p>

<blockquote>
  <p>I often use the direct port manipulation, I'd like to get an idea if
   it's neccesary for me to include these "precautions".</p>
</blockquote>

<p>If you use <em>constant</em> values, like <code>PORTB |= _BV(2);</code> or the like, there
is no need, since this compiles into a single CPU instruction. Even if
you write things that take multiple instructions,
like <code>PORTB |= _BV(2) | _BV(3);</code>, you probably know whether you are
modifying the same register inside an interrupt handler or not. If not,
no need for critical section either. The authors of the Arduino core
cannot make any assumptions.</p>
 4143: <blockquote>
  <p>I figure they don't want an interrupt to possibly change any of the bits in the output register while it executes *out = *out &amp; ~bit?</p>
</blockquote>

<p>Correct. That is known as a <em>critical section</em>.</p>

<blockquote>
  <p>And what would the SREG have to do with it? Could the code affect SREG and why would that matter?</p>
</blockquote>

<p>SREG is where the flag that says if interrupts are enable or not is stored.  Basically that is storing the current state, disabling interrupts, then restoring the current state.</p>

<p>The upshot is:</p>

<ul>
<li>If interrupts are enabled to begin with, they are disabled, then re-enabled.</li>
<li>If interrupts are disabled to begin with, they are again disabled, and they remain disabled.</li>
</ul>

<p>It's a way of restoring the previous state without actually having to check what the state was and set or clear accordingly.</p>
