Так и я о чём. В этом и был смысл поста 14-летней давности, но оно так не работает, как написано.
Так и я о чём. В этом и был смысл поста 14-летней давности, но оно так не работает, как написано.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Тут похожая ситуация:
1. Если исходно Aисх<x (в примере x=75), то на выходе A=Aисх+1
2. Если исходно FF>=Aисх>=x, то на выходе A=Aисх
- - - Добавлено - - -
Автор того поста не упомянул один момент - чтобы эти конструкции работали, надо чтобы исходное значение было "корректным" (>=x в случае декремента и <=x в случае инкремента).
Я понимаю.
Описанный алгоритм с декрементом работает не так, как написано. В приведённом примере, аккумулятор уменьшается до 22, хотя, как написано, он не должен уменьшаться меньше 23. Инкремент работает правильно, к нему претензий нет.
После 23446557465 итерации оставляет в аккумуляторе 22.Код:ld a, 30 err sub 23 adc a, 22 jp err
После 23446557465 итерации оставляет в аккумуляторе 23.Код:ld a, 30 err sub 24 adc a, 23 jp err
а что мешает сперва проверять, потом делать инкремент/декремент?
Код:CHECK_DN CP 23+1 ; A=23 min JR C,$+3 DEC A PROFIT ... ; уменьшаем до 23 CHECK_UP CP 55 ; A=55 max ADC A,0 PROFIT ... ; увеличиваем до 55
Весь смысл описанного кода как раз в отсутствии проверок и ветвлений.
Ну, в случае увеличения в моем варианте ветвлений нету, достаточно проверки. И по тактам, если кому критично, без расхождения.
С уменьшением простого решения нет. Либо раздувать код, либо ветвление.
Была бы у Z80 проверка сразу нескольких флагов, как на PDP - тогда, думаю, задача бы решилась.
Эти варианты имеют разную длительность. В первоначальном, 14-летней давности посте, это подчёркивалось.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)