CODING - THE оптимизация.

SoundTrack: BY 5EC70R/SERIOUS S.G.4 DEJAVU
__________________________________________


(C) M.M.A/SPEED CO. aka UnBELIEVER/XTM
__________________________________________


             THE ОПТИМИЗАЦИЯ


   В первых строках этой небольшой  статьи
я хотел бы отметить тот факт,что не считаю
                себя  крутым coder'ом. Да,
└S            когда-то были и у меня по-
c└S            зывы к овладению  програм-
╞└S            мированием   и  достижению
)┴S            высот SATISFACTION  и  IN-
М┴S            SULT - хитов  тех  далеких
я┴S            времен.  Однако  тотальная
R┬S            нехватка   усидчивости   и
╡┬S            свободного времени  вскоре
                привели к осознанию  факта
невозможности  стать  настоящим,  реальным
кодером. С тех пор, закрепив за собой ста-
тус человека знающего asm Z80,я стал зани-
маться более приближенными вещами на благо
любимого   SPECCY.  Конечно,  переодически
приходиться  грузить  ALASM  для написания
loader'ов,  простых процедурок для конвер-
сии/обработки графики и звука с pC, но это
совсем  не  то,  что я вкладываю в понятие
coder.  Вот почему, в нашей ENLIGHT'овской
работе  -  NOUMENON  - нет ни одного моего
бита в коде.

   Тем не менее, вышеперечисленные причины
не мешают мне пристально следить за совре-
менным состоянием дел в coding'е  и  прог-
раммировании. Именно по этому,найдя в при-
ложении к седьмому номеру ZX-FORMAT  новый
ассемблер  STORM, я  не  смог удержаться и
попробовал сей продукт в работе.

   Про STORM можно сказать очень много хо-
роших слов. Это абсолютно злая и  свирепая
среда. На мой субъективный взгляд, _насто-
ящие_  эффекты  не могут писаться в убогих
GENS/ZEUS/MASM  и  прочих. Хороший  эффект
требует  комфортного  написания, а STORM с
фреймовым  скроллингом  по  тексту  и есть
комфортная среда. Однако каждому свое...

   Так вот, сижу я в этом STORM'е и думаю,
чего  бы такого накодить. Наблюдая за быс-
трым скроллингом  экрана, я решил попробо-
вать  написать  что-то  подобное. Учитывая
приведенные  в  первом абзаце факты, ни на
что  большее, чем  скроллинг  всего экрана
вверх  с  очисткой  нижней  линии, меня не
хватило.  Написав  первый вариант, который
наконец, нормально заработал, я почувство-
вал  безумное  желание прооптимизировать и
ускорить  свою  программу.  Именно этому и
посвящены ниже написанные байты текста.

   Итак, наша с вами задача заключается  в
том, чтобы  написать процедуру, сдвигающую
весь  экран вверх на одну пиксельную стро-
ку. Далее, эту процедуру необходимо макси-
мально ускорить. Вот такие дела!

   Т.к. вы, мои дорогие читатели, наверня-
ка  не RST#7, EXPLODER  или  FUX, не будем
особо  круто ставить вопрос о сдвиге всего
экрана, например, за  время одного фрейма.
Нас вполне устроит два-три фрейма на сдвиг
то есть около 140-210 тысяч тактов. Именно
по  этому,  предлагаю  для самого процесса
копирования  одной  линии  не использовать
стековые конструкции POP all:LD SP,nn:PUSH
all,  трудно  понимаемые начинающими.  Да-
вайте ограничимся простыми и понятными ко-
мандами  копирования  блоков - LDIR, LDDR,
LDI, LDD.

   Для того,чтобы начать оптимизацию,нужно
набросать  первый вариант процедуры, к ко-
торому предъявляется всего два  требования
-  процедура  должна  правильно работать и
быть понятной. Чтобы не изобретать велоси-
пед,  ниже  я  привожу подобную процедуру,
которая  взята  из предыдущего номера DEJA
VU.  Моя  заслуга  здесь лишь в вызывающей
программе.

;-----------------------------------------
;   SIMPLE LDIR SCROLL CODED BY M.M.A
;     USING SUBROUTEN BY Serzh Soft
;-----------------------------------------


        ORG #8000


        LD HL,#C000,DE,#4000,BC,6144
        LDIR ;    Переброска на экран
;             загруженной с адреса #C000
;                    картинки

;-----------------------------------------
;   192 раза вызываем процедуру сдвига
;     экрана вверх на одну строчку
;-----------------------------------------


        LD B,192
LOO     PUSH BC
        DI
        CALL PSRL_UP
        EI:HALT  ;можно убрать для получе-
                 ;ния равномерного "подер-
                 ;гивания" строк.

        POP BC
        DJNZ LOO
        EI
        RET
;-----------------------------------------
; Сдвиг вверх на один пиксел (38<=91)
;-----------------------------------------


PSRL_UP
        LD DE,#4000;      10


;--
LP_PSU1 LD H,D;            4
        LD L,E;            4
        LD BC,#0020;      10
        INC H;             4
        LD A,H;            4
        AND #07;           7
        JR NZ,GO_PSUP;    10
        LD A,L;            4
        ADD A,C;           4
        LD L,A;            4
        JR C,GO_PSUP;      7
        LD A,H;            4
        SUB #08;           7
        LD H,A;            4
GO_PSUP PUSH HL;          11
        LDIR ;         21/16 всего=667
        POP DE;           10
        LD A,H;            4
        CP #58;            7
        JR C,LP_PSU1;      7 цикл=149553
;--

        XOR A;             4
LP_PSU2 LD (DE),A;         7
        INC E;             4
        JR NZ,LP_PSU2;    10 цикл=672

        RET ;всего около 151 тыс.тактов

   Все комментарии по работе  этого  блока
кода вы можете найти в DEJA VU#3/40 ЛУЧШИХ
ПРОЦЕДУР (ЛИСТИНГ 2). В  приведенном  выше
листинге вместо комментариев стоят  значе-
ния времени выполнения команд в тактах.

   Набрав и отассемблировав процедуру,  вы
должны загрузить с адреса #C000(49152) ка-
кую-либо графику, чтобы было что сдвигать.
Я рекомендую картинку aso scr.<C>, которую
можно  найти  на диске с DEJA VU#2. Дело в
том,  что эта картинка черно-белая и зани-
мает  весь  экран.  Это  позволит детально
пронаблюдать при скроллинге те места экра-
на, где луч развертки обгоняет нашу проце-
дуру обновляющую экран. А луч нас  обгонит
непременно, так как вся процедура занимает
около  151 тыс.тактов (более точно сказать
затруднительно,потому что нужно долго счи-
тать).  При подсчете тактов, я брал только
время  выполнения  процедуры  PSRL_UP  без
учета команды RET и вызывающей программы.

   Вот и пришло время  начать оптимизацию.
"Как?", спросите вы меня. Наивные люди, вы
полагали,  что я буду все объяснять доско-
нально и до последнего байта. Нет! Всю эту
грязную  работу  по  оптимизации предстоит
проделать  вам  и  только  вам. Кто из нас
двоих учиться ассемблеру, я или вы?

   Некоторые намеки придется все же  дать.
Конечно, следует  заменить  LDIR  на более
быстрый  LDI,  стек бля переброски графики
мы  договорились не  использовать! Однако,
стек  можно использовать для других целей,
там, где  метко  поставленный PUSH или POP
заменит  целую  прорву  команд. Непременно
нужно  ускорить  процесс перехода от одной
экранной строки к другой и,конечно же,сле-
дует.... Нет! Вы сами должны догадаться...
Хотя,  использовав  даже  половину из моих
подсказок,  вы сможете с легкостью достиг-
нуть отметки в 116  тыс.тактов, для  даль-
нейшего улучшения неплохо немного пораски-
нуть мозгами.

   Ну,а чтобы дать хоть какой-либо стимул, я
приведу  данные  по той процедуре, которую
удалось  написать  мне, придерживаясь ldir
ограничения на переброску строки:

Размер процедуры - 188 байт
(после первого запуска возростает до 572)


Примерное время  выполнения - 111 тыс.так-
тов  ( почти  точное  время  выполнения  -
110.682 )


   Для жаждущих взглянуть на этого  монст-
ра,в приложении к журналу помещен исходник
(файл называется LDISCROL.<C>). Я попросил
специально оставить его в формате STORM'а,
так  как  этот ассемблер есть не у всех, и
по  сему, вы скорее всего не сможете сразу
посмотреть в ответ. Придется немного поду-
мать тем местом, которое у некоторых назы-
вается головой.

   Конечно, я подозреваю и  сознаю, что  и
мою процедуру можно ускорить. Если же  во-
обще не двигать картинку на экране,а брать ее
из  памяти и выводить в нужном месте (даже
с  помощью LDIR'ов) , то...... Однако, это
совсем другая история!

    Powered by LACRIMOSA'95 "INFERNO"
      MOTHER RUSSIA/SAMARA/13.02.97

P.S. "Пятница 13-oe....."