Сейчас у меня большая загрузка разными делами, и времени на проект очень мало.
Но я успел выделить код intro в отдельный поток, сделать подготовку вспомогательных потоков, цикл обработки сообщений и проброс исключений из любого потока в основной поток (вернее, в обработчик сообщений). Также добавил экстренное закрытие intro по горячей клавише (пока без настройки, только Win+Ctrl+X) и ещё несколько опций.

Да, чуть не забыл. Упаковал 64-мегабайтный каркас API в чуть менее 600-байтный код (простым, RLE-подобным алгоритмом) и сделал распаковщик в память. Всё работает. Т.е. прямо сейчас можно запустить код такого вида (fasm):

format binary as 'll'

use32

call ebp
call dword [ebp-128]
call dword [ebp+eax]  ; eax при запуске = 0
jmp $

Все API пока содержат по-прежнему только ret, а выйти из jmp $ можно клавишей Win+Ctrl+X.
____________________

Я решил вместе с версиями давать программе кодовые имена: виды птиц 🕊

P.S. Кстати, вы знали, что волнистый попугайчик может развивать скорость до 100-120 км/ч? Прямо как морская чайка. Это примерно в 3 раза быстрее воробья 🦜

А крошечная колибри, летающая обычно со скоростью 48-85 км/ч, во время коротких перелётов может достигать скорости аж до 150 км/ч, делая при этом 50-80 взмахов крыльями в секунду (а во время ухаживания — до 200 взмахов, прямо как пчёлы) 🐝

Продумываю API.

Пока условно разбил основные функции на несколько групп:
🔸 0…-0x0F — control and miscellaneous functions;
🔸 -0x10…-0x2F — threading functions;
🔸 -0x30…-0x3F — video functions;
🔸 -0x40…-0x4F — sound functions;
🔸 -0x50…-0x5F — time functions;
🔸 -0x60…-0x6F — keyboard/mouse functions;
🔸 -0x70…-0x7F — file functions.

Может, чего-то забыл?

API FUNCTION CALLS

API functions are called by call dword [ebp+fn] (3-byte instruction, where fn is function number) or by call ebp (2-byte instruction) with function number in ah. Value in ebp is set on intro start and it's not recommended to modify it (however, it is not prohibited). If you have modified value of ebp you can use respectively call dword [API_TABLE_BASE+fn] (6-byte instruction) or call API_TABLE_BASE (call API_HANDLER is alias). Parameters are specified in al, edx and ecx registers. Result is returned in edx register or/and carry flag (CF). All other registers and flags are not modified.

For the best comfort use call_api macro with function number/name or ah as argument to call API function via ebp register. Use call_api_direct macro with function number/name or ah in parameter to call API function via API_TABLE_BASE. Function number will be placed in 32-bit register and this register can be specified as macro argument.

Examples:
🔘 call_api @CALL_IN_THREAD will be translated to call dword [ebp-0x10] (3 bytes).
🔘 call_api ah will be translated to call ebp (2 bytes).
🔘 call_api_direct ebx will be translated to call dword [API_TABLE_BASE+ebx] (6 bytes).
🔘 call_api_direct ah will be translated to call API_TABLE_BASE (5 bytes).

CONTROL AND MISCELLANEOUS FUNCTIONS

🔹 0 (@EXIT) — exit intro. Never returns.
🔹 -1 (@ABORT) — abort intro execution with no code. Never returns.
🔹 -2 (@ABORT_EX) — abort intro execution with code (ABORTCODE_*) specified in al. Never returns.
🔹 -4 (@SET_EXCEPTION_MODE) — set exception mode on wrong API usage: (al = 0 — disabled, return error result; 1 — enabled, generate exception). Default is disabled.

🔹 -0x1E (@SYNC_LOCK) — lock mutex exclusively / enter critical section for read and write access (al = mutex id). Returns CF: 0 — success; 1 — wrong al value on call.
🔹 -0x1F (@SYNC_LOCK_TIMEOUT) — lock mutex exclusively / enter critical section for read and write access with timeout (al = mutex id; ecx = timeout in milliseconds). Returns CF: 0 — successfully locked; 1 — time is out or wrong al value on call.
🔹 -0x20 (@TRY_SYNC_LOCK) — try to lock mutex exclusively / try to enter critical section for read and write access (al = mutex id). Returns CF: 0 — successfully locked; 1 — mutex is locked by another thread or wrong al value on call.
🔹 -0x21 (@SYNC_UNLOCK) — unlock exclusively locked mutex / leave critical section with read and write access (al = mutex id). Returns CF: 0 — success; 1 — wrong al value on call.
🔹 -0x22 (@SYNC_LOCK_SHARED) — lock mutex for shared ownership / enter critical section for read only access (al = mutex id). Returns CF: 0 — success; 1 — wrong al value on call.
🔹 -0x23 (@SYNC_LOCK_SHARED_TIMEOUT) — lock mutex for shared ownership / enter critical section for read only access with timeout (al = mutex id; ecx = timeout in milliseconds). Returns CF: 0 — successfully locked; 1 — time is out or wrong al value on call.
🔹 -0x24 (@TRY_SYNC_LOCK_SHARED) — try to lock mutex for shared ownership / try to enter critical section for read only access (al = mutex id). Returns CF: 0 — successfully locked; 1 — mutex is locked by another thread or wrong al value on call.
🔹 -0x25 (@SYNC_UNLOCK_SHARED) — unlock mutex locked with shared ownership / leave critical section with read only access (al = mutex id). Returns CF: 0 — success; 1 — wrong al value on call.

🔹 -0x26 (@WAIT_CONDVAR) — wait until condition variable is awakened, lock mutex exclusively (al = mutex / condition variable id (if high bit is set then mutex is already locked)). Returns CF: 0 — success; 1 — wrong al value on call.
🔹 -0x27 (@WAIT_CONDVAR_TIMEOUT) — wait (with timeout) until condition variable is awakened, lock mutex exclusively (al = mutex / condition variable id (if high bit is set then mutex is already locked); ecx = timeout in milliseconds). Returns CF: 0 — success; 1 — time is out or wrong al value on call.
🔹 -0x28 (@WAIT_CONDVAR_SHARED) — wait until condition variable is awakened, lock mutex for shared ownership (al = mutex / condition variable id (if high bit is set then mutex is already locked)). Returns CF: 0 — success; 1 — wrong al value on call.
🔹 -0x29 (@WAIT_CONDVAR_SHARED_TIMEOUT) — wait (with timeout) until condition variable is awakened, lock mutex for shared ownership (al = mutex / condition variable id (if high bit is set then mutex is already locked); ecx = timeout in milliseconds). Returns CF: 0 — success; 1 — time is out or wrong al value on call.
🔹 -0x2A (@NOTIFY_ONE) — notify one waiting thread (al = mutex / condition variable id). Returns CF: 0 — success; 1 — wrong al value on call.
🔹 -0x2B (@NOTIFY_ALL) — notify all waiting threads (al = mutex / condition variable id). Returns CF: 0 — success; 1 — wrong al value on call.

🔹 -0x2C (@CALL_ONCE) — call function once even if other threads try to call it (al = once flag id; edx = function address). Returns CF: 0 — success; 1 — wrong al value on call.

Total number of threads (including the main thread) can't be greater than 256 (in this API version). The main thread has index 0.
Mutex / condition variable id must be in range from 0 to 63 (in this API version).
Once flag must be in range from 0 to 63 (in this API version).

Конечно, в первую очередь я буду реализовывать другие группы функций ("control and miscellaneous functions" и "video functions"), а потом уже эту. Но описал пока "threading functions".

Ваши мысли, господа! 🙂

С новым 2️⃣0️⃣2️⃣3️⃣ годом, друзья! 🎄

Пусть в этом году сбудутся те мечты и достигнутся те цели, которые созвучны вашей душе! 🔥

Всем успехов в творчестве и в других сферах жизни! ❤️
Здоровья, бодрости, энергии и вдохновения! 🤩
Ура! 🥂 ✨

P.S. У каждого куранты бьют в разные моменты, поэтому отправляю по своему местному времени 🙂

Работа идёт, но пока медленно... В целом же, если реализовать буквально 2-3 API-функции (@INIT_VIDEO, @DISPLAY_IMAGE, ну и @PARALLEL_PIXELS), то можно уже пробовать делать интры и сравнивать скорость с другими платформами ✌️

————————————————————

Я тут иногда подумываю о названии проекта. Изначально была идея назвать его SEXI (что-нибудь типа Startup Environment for eXtra-speed Intros) или EROS (Environment of Runtime for Overclocked Scenes). Мне казалось это интересным, такой fun. Но многие восприняли такие названия с иронией. Не хотелось бы, чтобы люди относились к проекту несерьёзно.

Текущее название — Para\\e/
Хорошее, но какое-то… избитое что ли? Изюминки как будто не хватает. Но руки \e/ мне нравятся 🙂

Другие неплохие варианты:
🔸 F!RE (Fast Intro Runtime Environment).
🔸 loom (ткацкий станок). Потоки = треды = нити; генератор нитей = ткацкий станок.

Так себе варианты:
🔹 SPEED (Saucy Parallel Execution Environment for Demos).
🔹 FLIP (Fast Low-level Intro Platform).
🔹 PURE (Parallel Unified Runtime Environment). Чистый код — в смысле нативный, плоский.

Хочется отразить в первую очередь многопоточность (скорость), во вторую — нативность, низкоуровневость. И какую-то изюминку / перчинку добавить. Элемент креативности, озорство (но не клоунство 🤡).

Давайте подумаем! Подкиньте идей, друзья 😉

P.S. Всех с Рождеством! 🎄

Кстати, этот рисунок выводит 20-байтовая программа вот с таким исходником:

include 'parallel_fasm_sdk.inc'

CodeStart!

    apicall @InitVideo, (16-1) + (16-1)*ivHeightMult + ivPalette8bpp

@@: stosb
    inc al
    jnz B

    apicall @DisplayFrame, dfNoSync

    jmp $


Несмотря на то, что программа заканчивается инструкцией jmp $, из неё легко выйти двойным нажатием на Esc (можно и одинарным, но выход будет не сразу, а через секунду — это время даётся программе для отмены или корректного завершения). Либо комбинацией "быстро убить интро" Win+Ctrl+X.

Кстати, с прошлого поста я исправил несколько страшных багов, сейчас всё работает чётко 😎

Так что, теперь можно перейти к функциям работы с многопоточностью.

Поскольку многопоточность работает (и как мы видим по тестам, существенно ускоряет код), уже вполне можно писать интры, причём в хайрез и с использованием SIMD 😉
А я продолжаю думать о названии.

1️⃣ Помимо Para\\e/ и...
2️⃣ loom (главное, чтоб не было стойких ассоциаций с Java) появились ещё идеи.
3️⃣ artefact (что-то типа Advanced RunTime Environment For Art Code Threads, хорошо шарящие в инглише поправьте, плиз, если звучит странно).
4️⃣ Идея о F!RE трансформировалась в firebird (тем более, что я хочу называть версии видами птиц). Перевод с элементами фана: Fast Intro Runtime Environment (Brilliant Idea of Russian Developer) 😄. Смущают только возможные ассоциации с БД и, не дай бог, торпедой или ещё чем-то.
5️⃣ Ну и ещё интересное, на мой взгляд, имя — Para||ex (Parallel Environment of eXecution(?)). На Parallax аббревиатуру не придумал, но Parallex более оригинальное название.
6️⃣ Банальное: remi (Runtime Environment for Multithreaded Intros).

Что думаете? Об этих названиях. Ну и может, тоже идей подкинете? 🤔

⏸ Название определено (думаю, все уже заметили), больше мучить этим вас не буду 😃
Ссылки в телеге изменены, но старые тоже работают в режиме переадресации.

⏸ Хотел написать интру для Lovebyte 2023 под Para||elix, но не успел. Жаль, конечно. Но с другой стороны, есть возможность доработать и потом показать более полноценную версию.

⏸ Заметил, что legacy FPU работает пипец как медленно в сравнении со скалярным SSE/AVX (с векторным, думаю, будет такая же картина). По крайней мере, на Alder Lake. На Sandy Bridge замечал разницу, но не настолько большую. Вообще, странно, Instruction Tables (Agner Fog) показывает незначительные различия. В общем, чтобы говорить об этом более предметно, нужно потестить более обстоятельно. И на AMD в том числе.
Плюс вылезли вопросы сохранения FPU и SIMD-регистров (ибо некоторые API типа @GetDurationFloat — получение времени с момента старта, могут их портить).

⏸ Также задумался о 64-битной версии (на будущее). Раньше, конечно, тоже думал, но эта мысль казалось не столь интересной. По сути, интры получаются не шибко больше в размере, зато кол-во регистров удваивается (как общего назначения, так и SIMD). Но сложнее организовать API-вызовы по похожей схеме (т.е. call [ebp+fn], где fn — это любое число, сделать уже не получится). В общем, поживём — увидим. До этого ещё далеко.

⏸ Исправил баг: при использовании многопоточных функций интра висла через несколько секунд или минут. Причина была неочевидна, но чисто интуитивно решил положить notify_all внутрь залоченного мьютекса (раньше он был снаружи) — баг пропал :)

⏸ При старте интры, а также при вызове функций потоков (к примеру, для каждого пикселя) в регистр ebx теперь записывается выровненный по границе 256 байт адрес 4КБ буфера в TLS, т.е. потоко-локальной области. Это оказалось офигенно удобно. Т.е. вы можете хранить локальные переменные не только в стеке, но и в TLS, используя адресацию вида [ebx+n]. Потокобезопасно! Скажу по секрету, что можно адресовать не только в плюс, но и в минус (до 128 байт), т.е. у вас есть не 4КБ, а даже 4096+128 байт :)
Но, наверное, я расширю эту область до 64КБ (18МБ для 256+32 потоков — не так уж и много). Может, урежу стек (для каждого потока) до 512КБ (вместо дефолтного 1МБ) или даже до 256КБ (к чему такой большой?) 🤔

⏸ Поменял значение регистра ebp при старте интры. На нём завязана таблица API, а также зона сервисных данных. Раньше было ebp = 0x08000000 (напомню, что код грузится по адресу 0x10000000 (ebp*2), фрейм буфер — 0x40000000 (ebp*8)). Сейчас сделал ebp = 0x01C71C80. Это же гораздо лучше, согласны? 😀

Объясняю суть. При таком значении ebp можно использовать не только [ebp], но и [ebp+ebp], [ebp+ebp*2], [ebp+ebp*4], и [ebp+ebp*8], т.е. целых 5 вариантов почти за ту же цену (но первый всё же дешевле на байт) :)

✅ Первые 2 варианта (1x, 2x) можно зарезервировать для API (таким образом, кол-во функций увеличивается с 255 до 511 — с учётом возможных расширений, пусть будет).
✅ Следующий (3x) — для сервисных данных (инфа о процессоре, событиях (юзер нажал Esc), опциях, настройках видео и аудио, коэффициенты для приведения координат к диапазону 0..1, FP-координаты центра и т.д.). Причём, если раньше под них выделялось 128 байт, то сейчас можно 256 (128 оказалось мало).
✅ Ещё один (5x) — для хранения констант (0, 0.5, 1, π, 2π, e, √2 и т.д., включая векторные по 16 float'ов для SIMD вплоть до AVX-512).
✅ И последний [ebp+ebp*8] (9x) — это адресация 0x10000080 (теперь понятно почему 0x01C71C80?) Т.е. добавляя байтовую константу (-128..127) можно иметь доступ к первым 256 байтам кода (а сделав, скажем, lea edx,[ebp+ebp*8+127] — к смещениям 127..382 через edx). Тоже удобно.