Почему инструкции INC и DEC *не* влияют на флаг переноса (CF)?

Чтобы понять, почему вам, вероятно, нужно вспомнить, что нынешние процессоры «x86» с 32- и 64-битными значениями начали свою жизнь как гораздо более ограниченные 8-битные машины, восходящие к Intel 8008. (Я кодировал в этом мире еще в 1973 году, я до сих пор помни (тьфу) это!).

В том мире регистры были драгоценными и маленькими. Вам нужны INC/DEC для различных целей, наиболее распространенной из которых является управление контуром. Многие циклы включали выполнение «арифметики с множественной точностью» (например, 16 бит или больше!). Установив INC/DEC флаг нуля (Z), вы могли бы довольно хорошо использовать их для управления циклами; настаивая на том, чтобы инструкции управления циклом не изменяли флаг переноса (CF), перенос сохраняется между итерациями цикла, и вы можете реализовывать операции с множественной точностью без написания тонны кода для запоминания состояния переноса.

Это работало очень хорошо, как только вы привыкли к уродливому набору инструкций.

На более современных машинах с большими размерами слов вам это не нужно, поэтому INC и DEC могут быть семантически эквивалентны ADD ...,1 и т. д. На самом деле это то, что я использую, когда мне нужен набор переносов: - }

В основном я сейчас держусь подальше от INC и DEC, потому что они выполняют частичное обновление кода условия, и это может вызвать забавные задержки в конвейере, а ADD/SUB этого не происходит. Так что там, где это не имеет значения (в большинстве мест), я использую ADD/SUB, чтобы избежать киосков. Я использую INC/DEC только в тех случаях, когда код не имеет большого значения, например, вписывается в строку кэша, где размер одной или двух инструкций имеет достаточное значение, чтобы иметь значение. Это, вероятно, бессмысленная нано[буквально!]-оптимизация, но я довольно старомоден в своих привычках кодирования.

Мое объяснение говорит нам, почему INC/DEC установили нулевой флаг (Z). У меня нет особенно убедительного объяснения, почему INC/DEC устанавливают знак (и флаг четности).

РЕДАКТИРОВАТЬ Апрель 2016: кажется, что проблема зависания лучше решается на современных x86s. См. инструкцию INC против ADD 1: имеет ли это значение?

Вопрос о том, зачем подписывать, когда у вас есть флаг ноль, установленный inc/dec, лучше всего решать с помощью вопроса: вы бы предпочли обойтись без опции a ?

a) for (n=7;n>=0;n--)   // translates to   `dec + jns`
b) for (n=8;n>0;n--)    // translates to   `dec + jnz`

        mov cx, 10
begin:  lodsb
        rcr al,1   // this is rotate though carry:
        stosb      // for the algorithm to work, carry must not be destroyed
        LOOP begin //