Артём, спасибо, действительно душевно. Посетить пати у меня возможности не было, но атмосферу почувствовал, это главное. И, как настоящий софасценер, не могу не поблагодарить за отличные ссылки по касательной, особенно на книжку по real-time rendering и на MSDF. Реально вот этого в старых отчётах по-моему никогда не было, а я прямо с удовольствием потыкал и внёс в букмарки.
Какой же это потрясающий и невероятный репорт! Артёмка, спасибо тебе, что на какое-то мгновение вернул меня в те последние выходные уходящего лета :)
Таких мощных и атмосферных репортов не было последние лет 20, со времён бума спектрумовской прессы. На некоторых местах аж сердце зашлось, натурально… Надеюсь, люди прочитают это и поймут, что на пати на ездить. Всегда, и во что бы то ни стало.
В общем, я там был, Наки Томпсон пил, и подтверждаю, что именно так всё и было, по фактам!
Можно бесконечно спорить на частных примерах где получается больше, а где меньше. Но это не самоцель же на самом деле. Я просто показал в статье, что меня позабавило, что несмотря на очевидное разбазаривание плотности команд (у того же дедушки PDP-11 с наследниками в виде БК-шек она гораздо выше) весьма базовые действия такие как сложение слов с занесением сразу же результата в целевую ячейку памяти получаются заметно короче нежели на классических 8-битках. Многое конечно будет наоборот заметно больше — например нет ничего похожего даже на LDIR или инкремент регистра всегда осуществляется за слово, а не за байт (хотя инкремент может быть любым числом в диапазоне -8..+7 и может записать результат не в тот регистр из которого бралось первое слагаемое. собственно в архитектуре нет выделенной операции MOV потому что это инкремент на 0 какого-то регистра или ячейки памяти с занесением в другой регистр/ячейку памяти). Ну и тому подобное и так далее.
В 80-х такая архитектура не могла бы появится, потому что там более бережно отнеслись бы к расходу памяти и сделали бы что-нибудь типа PDP-11 или MSP-430. С их довольно ветвистыми системами команд и режимами адресаций.
Я же преследовал простоту всего — отказ от байта это в эту же копилку. Я прекрасно понимаю, что у Simpleton поэтому немало слабых сторон.
Но практикум программирования в эмуляторе показал лично для меня, что да, программировать просто — очень небольшой, буквально с час, период привыкания и всё, ты просто пишешь код состоящий из очень простых операций вида R = X op Y и многое о чём болела постоянно голова в Z80 или 6502 вообще отсутствует как класс.
локальные переменные — необязательно стековые, могут быть ведь и статические, где можно
Так с машинной точки зрения между статическими и глобальными разницы нет. Если статические — значит верно всё то что написано выше про глобальные.
ну вот, а у z80 — три байтика)))
С фига ли? Семь байт на _сложение двух слов из стека с записью результата в стек_. По любому смещению.
Три байта у Z80 тут даже близко нет.
вообще выигрыш у тебя больше за счёт 16-битности там, где от z80 ты тоже требуешь 16-битных операций
У Z80 есть 16-битные операции. И загрузка и сохранение и арифметика. Но вот…
При этом Simpleton субоптимальная архитектура — я писал про это в статье про сам Simpleton 4 в первых же параграфах. Её главная цель не вложить максимум команд в минимум байт, а обеспечить максимально чтобы были простыми одновременно и машинная и программистская стороны вопроса. Оптимальностью команд при этом пришлось пожертвовать, но что интересно — широкое слово даже после этого чаще всего обходит 8-битки по плотности команд когда действительно надо работать со словами. Даже если это такая мощная 8-битка как Z80 где обработка слов есть. Причём обходит заметно, причём разбазаривая биты и не делая сложных режимов адресации. Это забавно.
Это когда пошли процессоры заточенные под стековую адресацию.
локальные переменные — необязательно стековые, могут быть ведь и статические, где можно
На MOS6502 адресовать стек легко невозможно. На Z80 даже вроде бы при наличии адресации через IX/IY+offset такие инструкции дают приличный пенальти на работу со словами. Поэтому максимально быстрый код писался на глобальных переменных.
максимально быстрый код для восьмибиток пишется с удобным размещением данных
собс-но, в идеале что для локальных, что для глобальных адресов часто только младший байт изменяется
Семь слов если на стеке (и загрязнение трёх регистров). Против четырёх слов без загрязнения регистров у глобальных переменных.
ну вот, а у z80 — три байтика)))
вообще выигрыш у тебя больше за счёт 16-битности там, где от z80 ты тоже требуешь 16-битных операций
а на байтовых (например, при обработке текста) уже не всё так однозначно с твоим отказом от байта
P.S.
Правда еще надо заметить (по ссылке выше это описано) — если смещения от вершины стека переменных укладываются в -8..+7 слов, то размер примера [ a ] = [ b ] + [ c ] снова можно вернуть к четырём словам, но загрязнение регистров адресами локальных переменных останется. Причём если дальше нужно поработать с переменными отстоящими от уже полученных указателей опять же не далее чем на 4-битное знаковое смещение — опять можно обойтись в инструкции перенастройки одним словом. Короче inplace immediate может дать возможность к оптимизации. Но это так, полумеры.
всё же чаще в прикладных полезных программах оперируют локальными переменными
Это когда пошли процессоры заточенные под стековую адресацию.
На MOS6502 адресовать стек легко невозможно. На Z80 даже вроде бы при наличии адресации через IX/IY+offset такие инструкции дают приличный пенальти на работу со словами. Поэтому максимально быстрый код писался на глобальных переменных. Для меня это составляет некоторую романтику той эпохи поэтому инструкции адресации стека я вводить не стал.
так вот другой пример, на локальные — сложить два числа с верхушки стека, что будет здесь? ;)
Семь слов если на стеке (и загрязнение трёх регистров). Против четырёх слов без загрязнения регистров у глобальных переменных.
Я это обдумывал по следующей ссылке и там же придумал апгрейд архитектуры до лёгкой адресации стека: gamedev.ru/flame/forum/?id=249067&page=23&m=5439258#m333
Там как раз сперва рассуждения о том насколько просядет производительность с переменными в стеке.
А потом идея превратить один из пяти регистров без особых функций в аналог BP из i86: косвенные чтения/записи по регистру r4 всегда считывают слово из [ pc++ ], прибавляют его к r4 и полученное значение используется в качестве адреса для косвенного чтения/записи.
Тогда всё еще большую симметричность приобретёт: r0-r3 — регистры без специальных функций и r4-r7 — регистры особого назначения.
Но я не хочу так делать чтобы не ломать дух эпохи.
Хочешь Си — просади производительность. :)
Пример: берём три глобальных переменных var1, var2 и var3 и прокручиваем с ними на Си операцию:
всё же чаще в прикладных полезных программах оперируют локальными переменными
а глобальные — компиляторы стараются группировать с одной базой и адресовать потом по смещению
так вот другой пример, на локальные — сложить два числа с верхушки стека, что будет здесь? ;)
P.S.
В этом SimpX тоже пытается быть максимально простым и схемотехнически и программистски, но не экономией на спичках!
Текстовый видеорежим в нём является частным случаем графического режима. Идеи эти базированы очевидно на тайловых видеочипах консолей, но сделан тот ход, что номера тайлов в битмапе не линейно возрастают, а образуют двумерную картинку «as is» битмапа.
Но в статье описано, что перетусовки бит в этом случае настолько просты и прямолинейны, что не несут никаких накладных расходов по сравнению с линейной организацией тайловой карты.
В SimpX же это позволяет на одной и той же физической схеме реализовать и быстрый текстовый режим и линейный графический.
А при желании — демосценить с атрибутами знакомест! :D
и как архив без телеграма скачать?
Удивился, что так вообще можно :) Офигенная штука.
Таких мощных и атмосферных репортов не было последние лет 20, со времён бума спектрумовской прессы. На некоторых местах аж сердце зашлось, натурально… Надеюсь, люди прочитают это и поймут, что на пати на ездить. Всегда, и во что бы то ни стало.
В общем, я там был, Наки Томпсон пил, и подтверждаю, что именно так всё и было, по фактам!
А Артёмка красавчик! :)
Тёма, спасибо за столь обширную историю!
В 80-х такая архитектура не могла бы появится, потому что там более бережно отнеслись бы к расходу памяти и сделали бы что-нибудь типа PDP-11 или MSP-430. С их довольно ветвистыми системами команд и режимами адресаций.
Я же преследовал простоту всего — отказ от байта это в эту же копилку. Я прекрасно понимаю, что у Simpleton поэтому немало слабых сторон.
Но практикум программирования в эмуляторе показал лично для меня, что да, программировать просто — очень небольшой, буквально с час, период привыкания и всё, ты просто пишешь код состоящий из очень простых операций вида R = X op Y и многое о чём болела постоянно голова в Z80 или 6502 вообще отсутствует как класс.
а я говорил — «с верхушки» и не говорил про запись — так будет три
но вот не всегда они оправданы и нужны
С фига ли? Семь байт на _сложение двух слов из стека с записью результата в стек_. По любому смещению.
Три байта у Z80 тут даже близко нет.
У Z80 есть 16-битные операции. И загрузка и сохранение и арифметика. Но вот…
При этом Simpleton субоптимальная архитектура — я писал про это в статье про сам Simpleton 4 в первых же параграфах. Её главная цель не вложить максимум команд в минимум байт, а обеспечить максимально чтобы были простыми одновременно и машинная и программистская стороны вопроса. Оптимальностью команд при этом пришлось пожертвовать, но что интересно — широкое слово даже после этого чаще всего обходит 8-битки по плотности команд когда действительно надо работать со словами. Даже если это такая мощная 8-битка как Z80 где обработка слов есть. Причём обходит заметно, причём разбазаривая биты и не делая сложных режимов адресации. Это забавно.
максимально быстрый код для восьмибиток пишется с удобным размещением данных
собс-но, в идеале что для локальных, что для глобальных адресов часто только младший байт изменяется
ну вот, а у z80 — три байтика)))
вообще выигрыш у тебя больше за счёт 16-битности там, где от z80 ты тоже требуешь 16-битных операций
а на байтовых (например, при обработке текста) уже не всё так однозначно с твоим отказом от байта
Правда еще надо заметить (по ссылке выше это описано) — если смещения от вершины стека переменных укладываются в -8..+7 слов, то размер примера [ a ] = [ b ] + [ c ] снова можно вернуть к четырём словам, но загрязнение регистров адресами локальных переменных останется. Причём если дальше нужно поработать с переменными отстоящими от уже полученных указателей опять же не далее чем на 4-битное знаковое смещение — опять можно обойтись в инструкции перенастройки одним словом. Короче inplace immediate может дать возможность к оптимизации. Но это так, полумеры.
На MOS6502 адресовать стек легко невозможно. На Z80 даже вроде бы при наличии адресации через IX/IY+offset такие инструкции дают приличный пенальти на работу со словами. Поэтому максимально быстрый код писался на глобальных переменных. Для меня это составляет некоторую романтику той эпохи поэтому инструкции адресации стека я вводить не стал.
Семь слов если на стеке (и загрязнение трёх регистров). Против четырёх слов без загрязнения регистров у глобальных переменных.
Я это обдумывал по следующей ссылке и там же придумал апгрейд архитектуры до лёгкой адресации стека: gamedev.ru/flame/forum/?id=249067&page=23&m=5439258#m333
Там как раз сперва рассуждения о том насколько просядет производительность с переменными в стеке.
А потом идея превратить один из пяти регистров без особых функций в аналог BP из i86: косвенные чтения/записи по регистру r4 всегда считывают слово из [ pc++ ], прибавляют его к r4 и полученное значение используется в качестве адреса для косвенного чтения/записи.
Тогда всё еще большую симметричность приобретёт: r0-r3 — регистры без специальных функций и r4-r7 — регистры особого назначения.
Но я не хочу так делать чтобы не ломать дух эпохи.
Хочешь Си — просади производительность. :)
а глобальные — компиляторы стараются группировать с одной базой и адресовать потом по смещению
так вот другой пример, на локальные — сложить два числа с верхушки стека, что будет здесь? ;)
В этом SimpX тоже пытается быть максимально простым и схемотехнически и программистски, но не экономией на спичках!
Текстовый видеорежим в нём является частным случаем графического режима. Идеи эти базированы очевидно на тайловых видеочипах консолей, но сделан тот ход, что номера тайлов в битмапе не линейно возрастают, а образуют двумерную картинку «as is» битмапа.
Но в статье описано, что перетусовки бит в этом случае настолько просты и прямолинейны, что не несут никаких накладных расходов по сравнению с линейной организацией тайловой карты.
В SimpX же это позволяет на одной и той же физической схеме реализовать и быстрый текстовый режим и линейный графический.
А при желании — демосценить с атрибутами знакомест! :D