Можно бесконечно спорить на частных примерах где получается больше, а где меньше. Но это не самоцель же на самом деле. Я просто показал в статье, что меня позабавило, что несмотря на очевидное разбазаривание плотности команд (у того же дедушки 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
Вот тут есть старое видео графического режима: youtu.be/ESg7SWPMpE8
Тут видно, что выделяются знакоместа 8x8 пикселей.
И конечно это не просто так.
SimpX использует 16-цветный битмап 256x256 пикселей (видимая зона — 256x192), но каждое знакоместо 8x8 имеет собственный 4-битный атрибут палитры. Таким образом это эдакое мощное расширение спектрумных идей — в пределах знакоместа 16 цветов одной из 16 палитр (палитра содержит 15-битные RGB — 0RRRRRGGGGGBBBBB) так что всего на экране цветов может быть 256.
Более того зона атрибутов (32*32 слова) SimpX содержит так же индирекции какое именно знакоместо в текущем знакоместе выводится (0-1023).
Т.е. формат атрибута знакоместа в битах следующий:
PPPP00NNNNNNNNNN, где P — это номер палитры, а N — номер знакоместа которое в данном знакоместе выводится.
Если всю область чармапа залить нулями, то каждое знакоместо на экране будет выводить первый (нулевой) квадратик 8x8 из битмапа 256x256 — левый верхний уголочек. Если залить числом 1023 — то на экране 32*24 раз выведено будет нижнее левое знакоместо битмапа.
В любом случае манипулируя верхними четырьмя битами этой заливки можно окрашивать знакоместа в одну из 16 субпалитр.
Сейчас в simple_lib.inc эти характеристики используются чтобы организовать простейший текстовый видеорежим — битмап (16 килослов) заливается (частично) вот этой картинкой:
И чармап используется как буфер символов, т.к. они просто маппятся на эту картинку.
Если же залить чармап возрастающими от 0 до 1023 числами — то битмап будет отображён на экран прямолинейно как есть и даст графический режим с 16 цветами.
Который можно обогащать 16 субпалитрами добавляя к чарам в чармапе верхние 4 бита субпалитры.
это уже возможно, просто не хватает времени.
но да, если залить в чармап (1Rw) последовательно возрастающие числа, то битмап станет прямым отображением пикселей на экране.
это уже сейчас работает, но руки не доходят…
Итак, вкратце:
Берёшь два стереоканала на лучшей амиге.
@
Складываешь в один чтобы получить моно, как на худшем саундбластере.
@
Доказываешь всем как ты только выиграл.
Круто, чо. Ладно, ладно, амига круче, всем это и так давно понятно.
1. Означает. Абсурд — это утверждать, что один моно-канал лучше двух (которые на амиге очевидно получаются установкой одинаковой громкости в каждой паре левого-правого)
2. По ссылке вижу один пост страданий одного-единственного амижника с подключением амиги к чему-то-там. И не вижу каким образом несовершенство аудиосистемы амиги означает, что она хуже еще более несовершенного саундбластера.
3. Было сказано, что 16-битный звук на пц появился намного позже, а до этого б0льшую часть данной эпохи было 8 против 8 (и даже 8 против 14) при разнице по каналам минимум вдвое.
4. Так зачем же ты её начинал?
1. «И такого нет» не означает «лучше». Нерегулируемые 100% направо и налево — это абсурд, на «сцене» довольно много опытных музыкантов, которые это подтвердят.
2. Костылями на амиге добивались эффекта псевдо-стерео, инвертируя каналы и добавляя немного дилея, рекомендую ознакомиться со страданиями амижников, избавляющихся от этого прекрасного панорамирования, а заодно и со звуковой матчастью, там это всё описано.
Ещё раз отмечу, что в данном случае автор статьи прав, амижный звук в описываемой эпохе сильно уступал РСшному, как минимум про 8 vs 16 бит уже было сказано.
На этом пустую демагогию считаю законченной.
В моно и такого нет, тем и лучше; а если нужно моно, то имеем на амиге два моно-канала при равной громкости. И какого именно «эффекта» тут еще предполагается добиться «отдельными аппаратными микшерами»??
На классическом Спектруме демосцена несопоставима по масштабам с той, что была на C64/Amiga. Тот факт, что затем в России сделали свой Спектрум и на нём написали много классных демок — конечно здорово, но это капля в море. Мир не вертится вокруг России и бывшего СССР. В статье я специально показывал то, что считаю основой, а тому что из этого выросло — уделил намеренно мало внимания (например про современную PC демосцену там очень мало).
И ты явно воспринимал статью через призму своего мнения обо мне лично :-)
Кстати, думаю если бы ты изложил своё видение в собственной статье, все бы только спасибо сказали. Я бы с интересом почитал.
p.s. В детстве у меня самособранный Ленинград не сразу заработал, с тех пор ненавижу Спектрумы и мщу им. Даже на Enlight их пустил, чтобы реализовать эту свою ненависть ;)
В 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
Тут видно, что выделяются знакоместа 8x8 пикселей.
И конечно это не просто так.
SimpX использует 16-цветный битмап 256x256 пикселей (видимая зона — 256x192), но каждое знакоместо 8x8 имеет собственный 4-битный атрибут палитры. Таким образом это эдакое мощное расширение спектрумных идей — в пределах знакоместа 16 цветов одной из 16 палитр (палитра содержит 15-битные RGB — 0RRRRRGGGGGBBBBB) так что всего на экране цветов может быть 256.
Более того зона атрибутов (32*32 слова) SimpX содержит так же индирекции какое именно знакоместо в текущем знакоместе выводится (0-1023).
Т.е. формат атрибута знакоместа в битах следующий:
PPPP00NNNNNNNNNN, где P — это номер палитры, а N — номер знакоместа которое в данном знакоместе выводится.
Если всю область чармапа залить нулями, то каждое знакоместо на экране будет выводить первый (нулевой) квадратик 8x8 из битмапа 256x256 — левый верхний уголочек. Если залить числом 1023 — то на экране 32*24 раз выведено будет нижнее левое знакоместо битмапа.
В любом случае манипулируя верхними четырьмя битами этой заливки можно окрашивать знакоместа в одну из 16 субпалитр.
Сейчас в simple_lib.inc эти характеристики используются чтобы организовать простейший текстовый видеорежим — битмап (16 килослов) заливается (частично) вот этой картинкой:
И чармап используется как буфер символов, т.к. они просто маппятся на эту картинку.
Если же залить чармап возрастающими от 0 до 1023 числами — то битмап будет отображён на экран прямолинейно как есть и даст графический режим с 16 цветами.
Который можно обогащать 16 субпалитрами добавляя к чарам в чармапе верхние 4 бита субпалитры.
была опечатка
Имелось ввиду под Rw — K2 — килослова.
но да, если залить в чармап (1Rw) последовательно возрастающие числа, то битмап станет прямым отображением пикселей на экране.
это уже сейчас работает, но руки не доходят…
или огонь.Берёшь два стереоканала на лучшей амиге.
@
Складываешь в один чтобы получить моно, как на худшем саундбластере.
@
Доказываешь всем как ты только выиграл.
Круто, чо. Ладно, ладно, амига круче, всем это и так давно понятно.
2. По ссылке вижу один пост страданий одного-единственного амижника с подключением амиги к чему-то-там. И не вижу каким образом несовершенство аудиосистемы амиги означает, что она хуже еще более несовершенного саундбластера.
3. Было сказано, что 16-битный звук на пц появился намного позже, а до этого б0льшую часть данной эпохи было 8 против 8 (и даже 8 против 14) при разнице по каналам минимум вдвое.
4. Так зачем же ты её начинал?
2. Костылями на амиге добивались эффекта псевдо-стерео, инвертируя каналы и добавляя немного дилея, рекомендую ознакомиться со страданиями амижников, избавляющихся от этого прекрасного панорамирования, а заодно и со звуковой матчастью, там это всё описано.
Ещё раз отмечу, что в данном случае автор статьи прав, амижный звук в описываемой эпохе сильно уступал РСшному, как минимум про 8 vs 16 бит уже было сказано.
На этом пустую демагогию считаю законченной.
И ты явно воспринимал статью через призму своего мнения обо мне лично :-)
Кстати, думаю если бы ты изложил своё видение в собственной статье, все бы только спасибо сказали. Я бы с интересом почитал.
p.s. В детстве у меня самособранный Ленинград не сразу заработал, с тех пор ненавижу Спектрумы и мщу им. Даже на Enlight их пустил, чтобы реализовать эту свою ненависть ;)