Re: Another security vulnerability

mitchalsup@aol.com (MitchAlsup1) writes:

Thomas Koenig wrote:
>

MitchAlsup1 <mitchalsup@aol.com> schrieb:

Thomas Koenig wrote:
>

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:

Since each chased pointer starts back at LSQ, the cost is no different
than an explicit Prefetch instruction, except without (a),(b) and (c)
having been applied first.

>
I thought the important difference is that the decision to prefetch or
not can be done dynamically based on past history.

>

Programmers and compilers are notoriously bad at predicting
branches (except for error branches),

>
Which are always predicted to have no error.

>
There I mean that the programmer wrote the code::
>
     if( no error so far )      {
         then continue
     }
     else
     {
         deal with the error
     }
>
Many times, the "deal with the error" code is never even fetched.
>

On the second or third time, certainly.  Hmmm... given hot/cold
splitting which is fairly standard by now, do branch predictors
take this into account?

>
First we are talking about predicting branches at compile time and
the way the programmer writes the source code, not about the dynamic
predictions of HW.

gcc provides a way to "annotate" a condition with the expected
common result:

#define likely(x)     __builtin_expect(!!(x), 1)
#define unlikely(x)   __builtin_expect(!!(x), 0)

   if (likely(bus_enable.s.enabled)) {
      do something
   } else {
      do something else
   }

This will affect the layout of the code (e.g. deferring generation
of the else clause with the result that it ends up in a different
cache line or page).

It's used in the linux kernel, and in certain cpu bound applications.