Оптимизация в HL

[drbars]

я же тебе дал способ пересчета?
hl*#155
потом взять старшие 16 бит и сделать +1
drbars, а чего такое странное число? 149*3?

Умножение сожрёт всю выгоду на коротких прямых.
Странное число — максимальный размер буфера. Рациональное использование любого свободного кусочка.

первый inc hl заменить на inc l?

Посчитал, первый inc hl можно заменить, он не попадает в границу.

[jerri]

drbars, я к тому что у тебя максимальный размер линии 149 точек по вертикали

[char]

Посчитал, первый inc hl можно заменить, он не попадает в границу.

ok, при размере буфера менее 2 секторов, граница переходится 1 раз, ежели наметить переход на команду ldi, тогда и оба inc hl получится заменить на inc l?

... видимо, с заменой cp h на cp l ...

[drbars]

drbars, я к тому что у тебя максимальный размер линии 149 точек по вертикали

Игровое пространство 144 точки по вертикали.. буфер позволяет 149.

---------- Post added at 22:43 ---------- Previous post was at 22:29 ----------

ok, при размере буфера менее 2 секторов, граница переходится 1 раз, ежели наметить переход на команду ldi, тогда и оба inc hl получится заменить на inc l?
... видимо, с заменой cp h на cp l ...

Не получится наметить, я уже максимально оптимизировал. Старший адрес как раз и проверяет, закончился ли буфер.

85*3=255. Это значит что 2-ой INC HL попадает на границу. Если мы буфер на байт сдвинем, как из него выходить? L у нас может быть одинаковым 2 раза. Тут уже ничего не сделаешь.

Не забывай ещё, что буфер строится от конца к началу, а востанавливается от начала к концу.

[char]

Игровое пространство 144 точки по вертикали.. буфер позволяет 149.

---------- Post added at 22:43 ---------- Previous post was at 22:29 ----------



Не получится наметить, я уже максимально оптимизировал. Старший адрес как раз и проверяет, закончился ли буфер.

85*3=255. Это значит что 2-ой INC HL попадает на границу. Если мы буфер на байт сдвинем, как из него выходить? L у нас может быть одинаковым 2 раза. Тут уже ничего не сделаешь.

Не забывай ещё, что буфер строится от конца к началу, а востанавливается от начала к концу.

перепроверь, такой L будет только 1 раз (в конце), на проверку идет только 1 байт из трех.

видимо, A=255

[drbars]

перепроверь, такой L будет только 1 раз (в конце), на проверку идет только 1 байт из трех.
видимо, A=255

Ты от конца считаешь?

Пример:
Начало буфера #7E40
Конец буфера +1 = #8000

заполняем стеком по 3 байта.

LD SP,#8000

повтор N раз
PUSH AF
INC SP
PUSH HL

куда придётся граница 256-го?

[char]

ld sp,#7fff

выйдет только по этому адресу

#7eff на проверку не попадает, только #00 будет сравниваться с A (предыдущий же был #FD)

[drbars]

ld sp,#7fff

выйдет только по этому адресу

#7eff на проверку не попадает, только #00 будет сравниваться с A (предыдущий же был #FD)

Ок, теперь восстанавливаем в обратном порядке:

А = #80
HL = начало буфера.

RES_LN	LD E,(HL)
	INC L
	LD D,(HL)
	INC HL
	LDI
	CP H
	JP NZ,RES_LN
	RET

Что будет если А = #7F ?

[char]

ok, при размере буфера менее 2 секторов, граница переходится 1 раз, ежели наметить переход на команду ldi, тогда и оба inc hl получится заменить на inc l?

... видимо, с заменой cp h на cp l ...

sp=#7fff
...
заполнили буфер
...

a=#ff

...
ldi
cp l
jp nz,RES_LN


L при сравнении с A будет #ff только в конце.

[drbars]

sp=#7fff
...
заполнили буфер
...

a=#ff

...
ldi
cp l
jp nz,RES_LN


L при сравнении с A будет #ff только в конце.

Ладно, уговорил. Внесу fix.