Почему простого инвентирования MSB(и мб прибавления единицы, если MSB был ненулевым) недостаточно для смены знака?

попробуй ноль инвертнуть

достаточно для смены знака, но число будет другим

потому что так оно кодируется

Если в 64bit написать код:
mov al, [rip]
nop
То в al запишется 90h — следующий байт за командой, т.к. rip в то время будет указывать на nop.
При этом, как таковой команды mov al, [rip] не будет, но произойдёт подмена "rip" адресом в памяти следующим за этой командой, т.е. получится mov al, [n], где n — следующий адрес.
В 16/32 это не работает (mov al, [rip]).
А зачем это в 64 — без понятия. (Хотя, это будет короче чем call n в котором pop r, к примеру.)
На счёт pop rip — это скорее чья-то шутка.

Это вопрос очень сложный. Простой ответ на него такой: при  таком представлении отрицательных чисел они ведут себя "правильно" при любых арифметических операциях -- независимо, представляешь ты их как отрицательные или как положительные без знака; они позволяют заменить операции вычитания операцией сложения тд и тп. Короче говоря, происходит чёрная магия двоичной арифметики. Гениальное решение.

Кто-то может отладить в x64dbg этот код? (Тот случай когда команда lea действительно нужна.)

а что хотел сделать?

Эквивалентны ли эти два метода?

нет, первый случай считает следущий ip опкода, второй - текущий ip опкода

Это понятно, но заполнится ли от call весь регистр rbx?

конечно

адреса то 64битные

и стек при push/pop оперирует 8мью байтами, как и call/ret

Ок, x64dbg ругается на неверный формат PE?

попробуй .end start поместить на последней строке исзодника ( после определения ланных), в этом макросе также содержится определение секции импорта, поэтому надо всегда в конце

хотя вроде разницы нет

Экзешник же работает

как узнал, если отладчик его не щапускает? мож там винда его экстренно щакрывает

Но да, выкинул .data — x64dbg съел