Опасность устарела: несколько важных нюансов в новых стандартах C++

Если я правильно понимаю актуальную трактовку компиляторщиками, то поведение, как я описал.

Главное отличие ub - оно путешествует во времени. Т.е. программа может начать вести себя странно, ещё до того, как «произойдёт ub».

Unspecified ситуация всегда одинаково обрабатывается одной и той же версией компилятора

Если попробуете определить, что это значит, то окажется, что замена на op2 может быть корректной, или нет - по желанию реализации.

Но это всё эквилибристика. Реально нужно смотреть на то, как это компиляторщики интерпретируют.

Опасность устарела: несколько важных нюансов в новых стандартах C++

Если переполнение unspecified, то замена будет корректной. Даже если в каких-то случаях op2 падает.

Переполнение делают ub, чтобы адекватно анализировать пересечения циклов и пересечения указателей.

Опасность устарела: несколько важных нюансов в новых стандартах C++

Нет, потому что это ещё и зависит от трейса, который привёл к коду.

Например, какая-нибудь функция до нас могла записать адрес I в глобальную переменную, или вообще переслать в другой поток. Активация той функции уже закончилась, но…

Плюс обращу внимание, что это потребует всего кода процесса (т.е. мы запрещаем шареные либы, unfork, CreateRemoteThread и прочие системные вызовы), а также анализ псевдонимов, вроде, делается за экспоненциальное время…

Побеждаем компилятор в скорости при помощи ассемблера

Доступ к кешу имеет latency 4 цикла. С другой стороны, там взбухнет таблица переходов: больше нагрузка на icache и усложниться работа предсказателя ветвлений. Для меня неочевидно, что будет быстрее.@qw1 ответил Вам здесь

Возможно стоит посмотреть на компромисс: хранить в регистрах только два верхних элемента стека. Условно:

loop {
  if !has_x2 {
    x2 = pop();
    has_x2 = true;
  }
  match opcodes[ip] {
    Add => {
      x1 = x1 + x2;
      has_x2 = false;
    }
    Dup => {
      push(x2);
      x2 = x1;
    }
    // ...
  }
}

Такой подход, кажется более щадящим.

Также, если мне не изменяет память, то 3-4 регистра - оптимально для большинства кода на стэковой машине. Наращивать больше не очень эффективно. Но это, в основном учитывает арифметику; возможно специфика форта сдвинет данный оптимум.

Побеждаем компилятор в скорости при помощи ассемблера

Кажется, нагрузка на цикл декодирования будет выше, профита от такой оптимизации.

Rust и иммутабельность

Скорее создаёт новое имя, для существующего объекта. Чтобы создать место, имя нужно запинить.

Использование алгоритма бинарного поиска для нахождения квадратного корня числа на Java

Это неатомарное чтение. Оно невозможно в Яве. Даже для long-ов на 64битном компьютере.

Источником неатомарный чтений является не совсем кеш, а скорее отсутствие (атомарных) машинных инструкций на чтение/запись достаточной ширины. Но для Явы это неважно, потому что спека требует атомарности всех чтений (примитивов).

Как синхронизировать потоки в Java

Не очень понимаю, почему. У Вас же тогда может быть активны две критических секции одновременно: на разный нитях одного потока ОС. Или я Вас неправильно понимаю?