Продолжаю думать над организацией памяти.

Примерный Memory Map 32-битного процесса в Windows:
0x00000000 - 0x0000FFFF (64K) — резервная область (область нулевых указателей).
0x00010000 - 0x7FFDFFFF (почти 2 ГБ) — память, доступная процессу, включая DLL-ки в верхней части этой области.
0x7FFE0000 - 0x7FFFFFFF (128K) — системная область вперемешку с юзерской.
0x80000000 - 0xBFFFFFFF / почти 0xFFFFFFFF (1-2 ГБ) — память, доступная юзеру (соответственно в режиме PAE для 32-битной системы и в 64-битной системе), в 32-битной системе без PAE (или с отключенным битом 4G в PE недоступна).

Хочу сделать так, чтобы интра начиналась с фиксированного адреса.
Скорее всего, это будет адрес 0x10000000 (256 МБ от начала), потому что мне нужно от 64 до 80 МБ на API (ниже объясню почему) + память для самой среды запуска + адрес красивый и удобный :))

Если брать резерв доступной интре памяти в 1 ГБ для (включая сам код), то следующий свободный блок начнётся с адреса 0x50000000. Здесь, собственно, может начинаться видеопамять. Даже при 8K-разрешении 8192*8192*32 bpp на это нужно не более 256 МБ, т.е. на 0x60000000 всё закончится. Под DLL-ки оставшегося пространства хватит с лихвой.

Буферы под звук и пр. могут начинаться с любого адреса — это не шибко важно.

Теперь расскажу, зачем под API нужно аж 64-80 мегабайт. При старте интры регистр ebp будет указывать на область API-адресов: непосредственно по адресу ebp будет находиться 2-байтный jmp short (или 5-байтный jmp near, а пока думаю как лучше сделать, тут есть некоторые нюансы) на обработчик API, который выполняет функцию по её номеру в регистре ah, т.е. вызов API потребует всего 2 байта (call ebp), не считая загрузки номера в ah. По адресам [ebp-N] (N = -128...0, кроме 2-5 номеров) будут находиться 4-байтные адреса обработчиков API-функций. Чтобы все адреса были корректными, они должны содержать разные (неповторяющиеся) сочетания из 4-х цифр (к примеру, в 8 числах 1,1,1,1,2,1,1,3 у нас 5 валидных адресов: 0x01010101, 0x02010101, 0x01020101, 0x01010201, 0x03010102). Для 128 таких комбинаций диапазон адресов будет около 64 МБ. И такая организация позволит делать вызовы API-функций 3-мя байтами (call dword [ebp-N]) :)

В расширенной версии API с диапазоном в почти 256 адресов (позволяющей создавать соответственно около 256 функций) потребуется 80 МБ, т.к. 4-х цифр уже не хватит, нужно 5. Само собой, тут будет много пустых областей, которые не будут расходовать память. Ну и 1 ГБ + 256 МБ я выделять сразу не буду, достаточно только зарезервировать адресное пространство.

Кстати, кто знает, каков диапазон базового адреса загрузки PE-образа при ASLR ?
Если он может вылетать за пределы 0x01000000, думаю, стоит отключить его, чтобы он не порушил всю идею организации памяти 🤔

Как насчёт текстур?
Почему бы среде исполнения не сгенерировать случайные байты для intro? А шум Перлина? Или даже позволить пользователю (например, организатору пати) загружать свои текстуры (BMP/бинари, да хоть саундтрек!).
Тем более, у нас есть 4 незадействованные области примерно по 15МБ в зоне API (а в расширенном API их будет 5), чего им простаивать? 😁

Но это, скорее всего, будет реализовано позже, не в первой версии. Сейчас это не первостепенное.

THREADING FUNCTIONS

🔹 -0x10 (@CALL_IN_THREAD) — call function in a separate thread (edx = function address). Returns CF: 0 — success (edx = thread index), 1 — total number of threads is too large.
🔹 -0x11 (@TERMINATE_THREAD) — terminate thread (edx = thread index or 0 for all threads except main). Returns CF: 0 — success; 1 — thread is not running. Function with edx = 0 should be called only from the main thread (else exception is generated if exception mode is enabled)! It's not recommended to use this function!

🔹 -0x12 (@MULTI_CALL) — call function in many threads and synchronize (edx = function address; al = number of threads (0 — all free threads including current)).
🔹 -0x13 (@MULTI_CALL_NOSYNC) — call function in many threads and continue (edx = function address; al = number of threads (0 — all free threads)). Returns CF: 0 — success; 1 — no free threads (if al = 0 on call) or total number of threads is too large.
🔹 -0x14 (@MULTI_LOOP) — run loop, call function in many threads and synchronize (edx = function address; ecx = number of iterations).
🔹 -0x15 (@MULTI_LOOP_NOSYNC) — run loop, call function in many threads and continue (edx = function address; ecx = number of iterations). Returns CF: 0 — success; 1 — no free threads.
🔹 -0x16 (@MULTI_PIXELS) — call function for every pixel, pixel group or line of video memory in many threads and synchronize (al = number of pixels in group (must be 0 for line or 1, 2, 4, 8, 16, 32, 64 for pixel group); edx = function address). Returns CF: 0 — success; 1 — wrong al value or video memory is not initialized. This function shouldn't be called if video memory is not initialized (video mode is not set; exception is generated if exception mode is enabled)!
🔹 -0x17 (@MULTI_PIXELS_NOSYNC) — call function for every pixel, pixel group or line of video memory in many threads and continue (al = number of pixels in group (must be 0 for line or 1, 2, 4, 8, 16, 32, 64 for pixel group); edx = function address). Returns CF: 0 — success; 1 — no free threads, wrong al value or video memory is not initialized. This function shouldn't be called if video memory is not initialized (video mode is not set; exception is generated if exception mode is enabled)!

🔹 -0x18 (@WAIT_THREAD) — wait for thread function to finish execution (edx = thread index except 0). Returns CF: 0 — success; 1 — thread is not running, time is out or wrong edx value on call.
🔹 -0x19 (@WAIT_THREAD_TIMEOUT) — wait (with timeout) for thread function to finish execution (edx = thread index except 0; ecx = timeout in milliseconds). Returns CF: 0 — success; 1 — thread is not running or wrong edx value on call.
🔹 -0x1A (@WAIT_ALL_THREADS) — wait for all thread functions to finish execution. Returns CF: 0 — success; 1 — no threads are running or called not from the main thread. This function should be called only from the main thread (else exception is generated if exception mode is enabled)!
🔹 -0x1B (@WAIT_ALL_THREADS_TIMEOUT) — wait (with timeout) for all thread functions to finish execution (ecx = timeout in milliseconds). Returns CF: 0 — success; 1 — no threads are running, time is out or called not from the main thread. This function should be called only from the main thread (else exception is generated if exception mode is enabled)!

🔹 -0x1C (@SYNC_THREADS) — synchronize all threads (wait when all other threads call the same function or function @SYNC_THREADS_TIMEOUT).
🔹 -0x1D (@SYNC_THREADS_TIMEOUT) — synchronize all threads with timeout (wait when all other threads call the same function or function @SYNC_THREADS) or time will be out (ecx = timeout in milliseconds). Returns CF: 0 — successfully synchronized; 1 — time is out.

Вчера и позавчера исправлял механизм запуска потоков и блок отлова исключений (до этого был лишний re-throw в обработчике SEH, теперь всё чётко). Ну и перелопатил функции для работы с потоками (что выше присылал). Теперь хочу это список ещё укоротить (объединив некоторые функции), чтобы они влезли в один блок из 16 функций.

В связи с этим задумался вот о чём. Как удобнее передавать параметры: через регистры или через стек? Эволюция calling convention пришла к регистрам (в x86 был стёк, в x64 стали регистры для первых параметров), но хорошо ли это для интр?

С одной стороны, регистры — это скорость, нет лишних обращений к памяти (стеку), да и регистр можно переиспользовать, и если в нём уже есть нужное значение, не нужно делать лишний push. С другой — для интры привязка к регистрам означает неудобство, поскольку каждый регистр на счёту, и привязка к регистрам сковывает.

Эта мысль влечёт за собой следующую. Так как у меня 2 способа вызова API-функций: прямой вызов конкретной функции (call dword [ebp+fn]) и вызов по номеру в ah (call ebp), может, и номер функции для второго случая передавать через стек?

Идём ещё дальше: а как насчёт результатов? Стоит ли возвращать его в регистре (edx)? Может, и результат оставлять в стеке? И далее его можно будет pop-нуть в нужный регистр, не затирая значение в edx.

Что думаете об этом?
Сейчас создам опрос :))

update: Опрос создал в чате (нажмите на комментарий и проголосуйте, пожалуйста, вдумчиво) 😉

Итак, друзья! Первые видимые результаты: я реализовал функции @InitVideo и @DisplayFrame. Всё работает, картинка выводится 😁

Про скорость пока могу сказать только следующее: вывод xor-шаблона в 480х270 с масштабированием на FullHD даёт у меня порядка 1500 fps. Вывод в 1920x1080 — в 2 раза медленнее.

Многопоточность ещё не задействовал.

Сгенерировал палитру по умолчанию для 8-битных режимов. Провозился целых 3 дня, но сделал вариант, который, вполне нравится.

На всякий случай опишу 😁
1️⃣ Первый ряд — ч/б градиент от чистого чёрного до чистого белого.
2️⃣ Далее 12 цветных рядов от самого тёмного до почти белого. Чистый цвет на 11-й позиции каждой строки (считая с 0). Соответственно, слева 11 затемнённых, справа 4 осветлённых цвета. Палитра начинается с голубого как более близкого к белому.
3️⃣ Следующий ряд — 12 радужных цветов со значительной примесью серого (более мягкие, не такие кислотные, как те, что выше) + 4 цвета с лёгкой примесью серого.
4️⃣ Последние 2 ряда — цвета палитры SWEETIE16, расширенные до 32 штук интерполяцией (могут использоваться циклически).

Все цвета сначала генерируются линейно, после чего производится гамма-коррекция с коэффициентом 1/1.2 (т.е. все значения во float в диапазоне [0; 1] возводятся в степень 1.2). Число выбрано эмпирически как более-менее оптимальное: меньшее значение (1.0) — слишком много ярких тонов, большее (1.333) — слишком много тёмных. Понятно, что многое зависит от настроек монитора и индивидуальных особенностей восприятия, но я решил сделать так.

В целом я доволен. Немного смущает вырвиглазность цветов (за исключением 3-х нижних рядов). Но потом я планирую сделать альтернативную (может, даже не одну) палитру с более мягкими цветами. Либо взяв за основу эту, либо просто большой градиент от чёрного в белый, переходящий в радугу, и в конце снова уходящий в чёрный.

К тому же, я собираюсь сделать функции генерации палитры :)