Привет, друзья.

Хочу поделиться с вами своими наработками. Сперва хочу извиниться за то, что постоянно буду использовать свой ассемблер ASAM. Увы, он работает только под 32-бита, у этого есть ряд причин, но почему это так, — не сейчас.

Теперь о сегодняшней теме, о параллельных потоках. Начиная с 2003 года я постоянно использую два типа потоков на Speccy: первый, мой любимый — это сквозные функции; и второй, о котором пойдёт речь — это классические потоки. Я приведу пример самых простых потоков, и если вам это нужно — вы легко сможете доработать его до своих нужд.

Thread'ы очень просты. Всё сводиться к двум основным процедурам — это создание и переключение потоков. Текущий вариант потоков эволюционировал из простых переключений между блоками памяти в переключение между страницами, что очень удобно для decrunch'ингов чего-нибудь, или для распаковок данных. Хочу отметить, что впервые оправданное использование потоков я ощутил при coding'е под ts-conf'у.

Как работают потоки в моём варианте. Переключатель потоков происходит на прерываниях. Поэтому предполагается, что мы в режиме IM2, и каждая задача переключается сразу после окончания прерывания, при том условии, что он в режиме idle — потоку нечего делать, и он исполняет циклически процедуру SwitchThread.
Это очень удобно, поскольку прерывание начинается с PUSHA, и всегда заканчивается POPA.
Вот, в аккурат перед POPA и происходит вызов процедуры CALL_SwitchNextThread, которая подставляет стек и страницу нужного потока. Все переключения страниц — вне прерывания, а значит внутри потока, и они происходят вызовом процедуры OutBC. Согласен, что вызов процедуры OutBC занимает такты, но при этом отсутствуют коллизии, и нам не нужно задумываться — где и какая страница включена.

В процедуре переключение страниц учитывается текущий отображаемый экран.

OutBC:  PUSH BC AF
        AND 11110111B
        LD B,A
        LD A,(OutSCR)
        OR B
        LD (OutPort),A
        LD BC,32765
        OUT (C),A
        POP AF BC
        RET

Теперь о самой процедуре переключения потоков, вызываемой из прерываний:

CALL_SwitchNextThread:
        POP HL
        LD (SWTHRx7+1),HL
        POP DE          ;GET PAGE INFORMATION
        IORQ.MAC.THREAD_BEFORE
        LD HL,(THREAD_REC_PTR)
        LD (SWTHRx1+2),HL
SWTHRx1 LD (0),SP
        INC HL
        INC HL
        LD (HL),E
        INC HL
        LD (HL),D
        INC HL
        LD SP,StackThreadSwitchSP
SWTHRx3 LD (THREAD_REC_PTR),HL
        LD E,(HL)
        INC HL
        LD D,(HL)
        INC HL
        INC HL
        INC HL
        LD A,E
        OR D
        JP Z,SWTHRx3
        LD A,E
        DEC A
        OR D
        JR NZ,SWTHRx2
        LD HL,THREAD_REC
        JP SWTHRx3
SWTHRx2 LD (SWTHRx4+1),DE
        DEC HL
        LD D,(HL)
        DEC HL
        LD E,(HL)
        IORQ.MAC.PAGE_RESTORE_DE
SWTHRx4 LD SP,0
        IORQ.MAC.THREAD_AFTER
        PUSH DE
SWTHRx7 JP 0

Вот собственно это основа, которая будет вам переключать потоки. Немного разберём код. Я большой любитель макросов, они дают возможность делать переносимый код на разные платформы. Макрос IORQ.MAC.PAGE_SAVE и IORQ.MAC.PAGE_RESTORE — эти макросы определяются персонально для нужной модели.

Например для режима ZX это будет выглядеть так:

        .IORQ.MAC.PAGE_SAVE
         LD A,(OutPort)
         PUSH AF
        ..

        .IORQ.MAC.PAGE_RESTORE
         POP AF
         CALL OutBC
        ..

… а для TS-CONF так:

        .IORQ.MAC.PAGE_SAVE
         PUSH HL
         PUSH BC
         LD BC,TSL.RAMPage2
         IN L,(C)
         INC B
         IN H,(C)
         POP BC
         EX (SP),HL
        ..

        .IORQ.MAC.PAGE_RESTORE
         EX (SP),HL
         PUSH BC
         LD BC,TSL.RAMPage2
         OUT (C),L
         INC B
         OUT (C),H
         POP BC HL
        ..

Таким образом я компилирую два вида кода, каждый из которых под нужную платформу, и в обоих вариантах на стек сохраняется, и восстанавливается активная в в текущий момент страница. В режиме ZX на стек сохранится два байта, из которых один — это страница, а в режиме TS будет два байта — для page2 и page3.

Теперь про IORQ.MAC.THREAD_BEFORE и IORQ.MAC.THREAD_AFTER.
Это очень важные макросы, позволяющие на стек сохранить нужные вам параметры. В режиме ZX у меня там пустышки, как бы регистров и страницы для каждого потока хватит за красивые глаза. Но вот в режиме TS у меня там хранятся регистры DMA, что даёт возможность в двух потоках параллельно использовать DMA.

TS слишком сложен, что бы к работе с ним подходить по классике ZX'а. Поэтому в режиме работы TS код этих макросов выглядит вот так:

        .IORQ.MAC.THREAD_BEFORE
         PUSH BC AF
         IORQTS.MAC.DMA_WAIT
         POP AF BC
         IORQTS.MAC.DMA_ALL_REG_PUSH   ;PUSH DMA REG x8 Byte
        ..

        .IORQ.MAC.THREAD_AFTER
         IORQTS.MAC.DMA_ALL_REG_POP    ;POP DMA REG x8 Byte
        ..

Однако, в примере под TS я так же сделал пустышки, поскольку эти макросы — часть основного движка. Если я его сюда прикручу, то будет очень сложно понять что к чему.

Теперь давайте рассмотрим как выглядит обработчик прерывания:

INT:    PUSHA
        IORQ.MAC.PAGE_SAVE
        LD (INx5+1),SP
        POP HL
        LD SP,StackIntSP        ;STACK FOR INTERRUPT
        PUSH HL
        CALL EFFECT             ;INTERRUPT PROCEDURES
        IORQ.MAC.PAGE_RESTORE
INx5    LD SP,0
SWTHRx8 CALL CALL_SwitchNextThread
        LD A,205
        LD (SWTHRx8),A          ;EI FOR INTERRUPT THREAD SWITHCER
        IORQ.MAC.PAGE_RESTORE
        POPA
        EI
        RET

На прерывании мы сохраняем страницу (или страницы) — в зависимости от конфигурации (ZX или TS), исполняем EFFECT, сразу после чего переключаем поток. Если поток у нас один, то он автоматом будет сохраняться и тут же восстанавливаться.
Ещё хочу обратить внимание на StackIntSP, тут у меня буфер для прерывания, размер которого отдельно конфигурируется в зависимости от модели платформы. Например для ZX мне всегда хватает 64 байта, а вот в TS уже надо 128 байт.

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

Теперь про SwitchThread:
Эту процедуру нужно вызывать тогда, когда вы чётко знаете, что в текущем потоке вы всё сделали и готовы отдать оставшееся время процессора на соседний поток.

SwitchThread:
        PUSHA
        IORQ.MAC.PAGE_SAVE
        LD A,33
        LD (SWTHRx8),A          ;DI FOR INTERRUPT THREAD SWITHCER
        CALL CALL_SwitchNextThread
        LD A,205
        LD (SWTHRx8),A          ;EI FOR INTERRUPT THREAD SWITHCER
        IORQ.MAC.PAGE_RESTORE
        POPA
        RET

Обратите внимание, что постоянно защёлкивается переключатель потоков на прерывании с помощью отключения вызова процедуры по адресу SWTHRx8. На прерывании я его всегда возвращаю в режим вызова процедуры, в вот в процедуре SwitchThread — можно убрать восстановление вызова переключателя потоков.

Это даст возможность регулировать приоритеты. Ведь, по сути, если от прерывания для соседнего потока вы оставили времени на 200 тактов, то ровно столько будет исполняться соседний поток, и тут же на прерывании переключится назад. Это будет не очень честно, но зато в текущем режиме, в не честном, можно делать потоки ONE-FRAME, что благополучно используется в gift'е дорогому Вовке. Вот там в одном потоке — генерируется очередной эффект на заднем плане, а на втором потоке — летают буквы по экрану. И это самые, что не на есть честные потоки, которые крутятся ONE FRAME.

А вот так будет выглядеть основной код, с использованием этих процедур:

ORG 32768
       CALL SysInit
       LD HL,ThreadInThePAGE
       CALL CreateThreadCopyCodeBlockPTR
MLOOP  LD A,2
       OUT (254),A
       CALL SwitchThread
       JR MLOOP

ThreadInThePAGE
      MAC.ThreadBegin 0C080H, 17
THPAx1 LD A,1
       OUT (254),A
       CALL SwitchThread
       JR THPAx1
      MAC.ThreadEnd

Этот пример создаст второй поток по адресу 0C080H, в странице 17, а основной исполняемый код автоматом становится первым потоком. Причём при создании потока он данные скопирует из адреса ThreadInThePAGE, в 0C080H, ну а текущие данные можно использовать как угодно.

Ещё особенность: перед данными кода по адресу 0C080H будет располагаться стек этого потока, и глубина его будет, как вы уже догадались, 128 байт. Один поток будет стремиться переключить бордюр в красный цвет, а второй поток в синий, ну и прерывания что-то там будут делать, например играть музыку, эффекты всякие показывать.

В примере есть два макроса MAC.ThreadBegin и MAC.ThreadEnd, они создадут перед и после потока заголовок для переброса данных в страницы. Так же код потока будет между командами компилятора Phase 0C080H и UnPhase. В общем — я любитель автоматов, что бы всё выглядело красиво.

Вот тут можно скачать пример.

Распишу более детально что там внутри.

Два главных файла:
THZX.AZ8 путь для режима ZX
THTS.AZ8 путь для режима TS
В этих файлах и запускается пример кода потоков.

SYS.AZ8 и к нему под нужную платформу SYSZX.AZ8, SYSTS.AZ8 — конфигураторы и процедуры для переключения памяти. А так же прерывания и процедуры работающие с потоками.

Так-же в архиве находится сам компилятор ASAM.EXE и THREAD.BAT, который всё скомпилирует и поместит итоговый результат в THREAD.TRD.

Далее — дело техники.