[quote="Hishnik"]Формально 0-операндный процессор при хороших условиях однозначно выигрывает. Вопрос только в том, не поставят ли его в нехорошие условия, заставив держать на стеке много переменных и постоянно жонглировать ими. Но есть предварительное ощущение, что "существует класс алгоритмов, для которого 0-операндный процессор покажет наилучшую плотность кода".[/quote]Ах, да, я ж как раз и подразумевал стековые процессоры, просто не указал это явно. И хотел сравнить их по плотности между собой, а не с регистровыми.
Пока делал только 3/4/6-битные Форт-процессоры. 4/6-битные почти для всех скомпилированных примеров дают заметно более плотный код в сравнении с условными x86/6502/AVR/etc. Вполне допускаю, что есть примеры, на которых эти стековые процессоры уступят, но пока не встречались такие. 3-битные, естественно, послабее, да и сделаны, если честно, для галочки, но даже они часто опережают регистровые процессоры по плотности. Стековые между собой соотносятся примерно так (и для сравнения в таблицах пара регистровых):

dhrystone:[code]c/asm cpu cmd code data size
vbcc 6502 10819
tcc x86 7168
uc f3H 11019 4133 1820 5953
uc f4B 3900 1950 1820 3770
uc f61 2410 1808 1820 3628[/code]
Интерпретатор basic:[code]c/asm cpu cmd code data size
tcc x86 5120
uc f3H 9004 3377 109 3486
uc f43 3369 1685 109 1794
uc f61 1830 1373 109 1482[/code]
Если грубо, то 3-битные уступают 4-битным раза в 2, а 4-битные - процентов на 10-20% 6-битным. Понятно, что в зависимости от теста разница может уползать в ту или иную сторону. Но точно все 3-битные сильно уступают 4-битным, а все 4-битные уступают единственному пока 6-битному. Но это именно на моих процессорах/компиляторах. А у кого-то другого могут получиться совершенно другие результаты.
Вообще, интересно было бы сделать 5-битные команды, а также 8/9- и 16/18-битные. А еще могут быть комбинированные варианты, в которых либо длинный литерал, либо несколько упакованных команд небольшой длины.
Почему-то не покидает ощущение, что 8/9-битные дадут более плотный код в сравнении с 16/18-битными, а вот что будет в сравнении с 4/5/6-битными, пока сказать сложно.

[quote="Hishnik"]Тут ведь вопрос в том, сколько переменных одновременно "живы" (т.е. от начала упоминания в правой части выражений и до последнего присваивания). Если таких много, их хотелось бы один раз прочитать в регистры и потом ими пользоваться. А если это 123 A ! 345 B !, то тут много регистров и не надо, вполне хватит стека и 0-операндной системы команд. Поэтому можно сразу обратиться к компиляторам, абстрагированным от регистровой модели, и попробовать с их помощью сгенерировать код под разные варианты.[/quote]В идеале тут нужен компилятор, который сразу заточен на стековость процессора.

Что-то Брусом навеяло такой челлендж: по одному блоку BRAM на видеопамять, RAM, ROM и шрифты/спрайты. Такой вот экстремальный минимализм. И что можно выжать из этого безобразия? :) В теории оно потом влезет в Tang Nano 1K, где как раз 4 блока на борту, а может даже в 5510, хотя в последней нет BRAM.

[quote="Total Vacuum"]Интересно все-таки, какой ширины машинное слово дает максимальную плотность кода?[/quote]
О, это замечательная тема! Тут ведь вопрос в том, сколько переменных одновременно "живы" (т.е. от начала упоминания в правой части выражений и до последнего присваивания). Если таких много, их хотелось бы один раз прочитать в регистры и потом ими пользоваться. А если это 123 A ! 345 B !, то тут много регистров и не надо, вполне хватит стека и 0-операндной системы команд. Поэтому можно сразу обратиться к компиляторам, абстрагированным от регистровой модели, и попробовать с их помощью сгенерировать код под разные варианты.

Формально 0-операндный процессор при хороших условиях однозначно выигрывает. Вопрос только в том, не поставят ли его в нехорошие условия, заставив держать на стеке много переменных и постоянно жонглировать ими. Но есть предварительное ощущение, что "существует класс алгоритмов, для которого 0-операндный процессор покажет наилучшую плотность кода".

[quote="Hishnik"]Если заводить стековый фрейм, система команд становится смешанной - стеково-регистровой. Не принципиально, будет это абсолютный индекс регистра, или его смещение относительно вершины стека, придется заводить в команде соответствующие поля, и тогда размер кода увеличится. Вообще это можно делать, просто надо сразу посмотреть, во что превратятся типовые программы. Вполне может получиться, что смещения будут болтаться около вершины, и существенной разницы по быстродействию не получится, а вот эти небольшие смещения будут тратить место в командах.[/quote]Ну в Брусе не совсем классический фрейм, он только для локальных переменных, но не для аргументов функций (для них отдельный аппаратный стек есть). Если я правильно путаю, именно в таком виде сейчас реализовано в Питоне под Брус. В моей реализации Си для Бруса аргументы тоже через стек, локальные в массиве (так исторически сложилось), а фрейм не используется.
Очевидно, что при проектировании системы команд учитывалось, что под Брус будет компилятор ЯВУ, поэтому заранее подстелили соломку в виде фреймов на случай, если вдруг будут локальные переменные (а почему бы им и не быть?). Ну и раз уж выбраны достаточно широкие команды (16 бит), то нужно максимально заполнять их, чтобы не гонять туда-сюда полупустые инструкции. :)
Интересно все-таки, какой ширины машинное слово дает максимальную плотность кода?

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

[quote="KPG"]Подумалось[/quote] :) В теории тут разные фокусы с фреймом возможны, система команд это позволяет, т.к. в команде LOCALS, которая выделяет место под фрейм, могут быть закодированы в т.ч. и отрицательные значения. На практике, однако, родной компилятор Питона, насколько мне известно, задумывался и разрабатывался в высшей степени простым: [url]https://github.com/true-grue/Brus-16/blob/main/tools/brus16_dsl.py[/url]
А там строго: вошли в подпрограмму - выделили место под фрейм, выходим из подпрограммы по RET - освобождаем. Впрочем, никто не запрещает на ассемблере писать, а в нем любые трюки возможны, даже самые экзотические. Ну, например, стек на базе FP программно организовать.
Что касается моего компилятора Си под Брус-16, то там фрейм и вовсе не используется, локальные переменные размещаются в массиве, а предназначенные для чтения/записи локальных переменных команды GET_LOCAL/SET_LOCAL иногда использую вместо LOAD/STORE для чтения/записи глобальных переменных, так тоже можно, если обнулить регистр FP.

Вторая статья про Брус-16 - "64 прямоугольника хватит всем"
https://habr.com/ru/companies/yadro/articles/1040288/
или на "зеркале" статей с Хабр (без лишнего трафика) https://forpes.ru/post/231238

P.S. Подумалось, если в процессоре используется фрейм локальных переменных, то может имеет смысл, в каких то случаях, сохранять его данные для повторного использования и при этом вызываемой подпрограмме передавать счётчик её вызовов (автоматически наращиваемый или скорректированный), чтобы следующий вызов кода этой подпрограммы при исполнении смог его использоватть для вариативного своего исполнения (например изменения локальных каких то входных данных фрейма, чтобы их повторно не передавать во фрейм локальных данных от основного кода), сама подпрограмма тоже может его изменять. Каким то подпрограммам этот фрейм может удаляться вызвавшим кодом (Си нотация) или подпрограммой (Паскаль нотация)

Как это лучше реализовать и утилизировать и имеет ли такая идея какой то смысл пока не понятно, например по ресурсам для её реализации и что она даст в итоге.
Интуитивно, мне эта идея нравится.:)

:) Да, кстати, статья про Брус-16 на Хабре:
[url]https://habr.com/ru/companies/yadro/articles/1023972/[/url]

В этих ваших интернетах пишут, что Спектруму сегодня 44 года. Вспомним старичка добрым словом:
[url]https://idpixel.ru/news/3464-kompjuteru-zx-spectrum-segodnja-ispolnilos-44-goda/[/url]

Кстати, в Брус-16 звук появился, можно в Герионе заценить:
[url]https://true-grue.github.io/Brus-16-Apps/brus16.html[/url]
А еще можно определить год выпуска процессора по количеству годовых колец на срезе. И мох растет с северной стороны процессора. Насчет последних двух пунктов не уверен, а вот звук точно есть :)

Еще бы! Я тут еще на PSRAM облизываюсь. 64 Мбит, но интерфейс SPI x4, много не вытащить. А такой бы замечательный видеобуфер получился!

:D Год закончен, но итоги не подводим, тему не закрываем. Свободное время рано или поздно появится, так что продолжаем разговор. Не переключайтесь, будет интересно :)
[img]http://totalvacuum.ru/BATTLE/minemario.jpg[/img]
[url=http://totalvacuum.ru/BATTLE/minemario.jpg]ссылка на изображение[/url]

Исходники порта Alter Ego под Брус-16, текущее состояние дел:
[url]http://totalvacuum.ru/BRUS16/alterego.zip[/url]
Собирается через alterego.bat, на выходе имеем "исполняемые" html (можно в браузере погонять) и bin. И даже на Tang Nano 9K запускается :)
[img]http://totalvacuum.ru/BRUS16/aetn9k.png[/img]
[url=http://totalvacuum.ru/BRUS16/aetn9k.png]ссылка на изображение[/url]

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

И полтора месяца на все! За такое время иногда успевают только ТЗ с ленцой пролистать.

Кстати, посмотрите, например, Gerion или Robot
[url]https://true-grue.github.io/Brus-16-Apps/brus16.html[/url]
Порой даже не верится, что удается уложиться в 64 цветных прямоугольника. А от Гериона в некоторых уровнях даже волосы стынут в жилах :D
Просто для сравнения: в знакоместе 8x8 64 пиксела, а тут вроде как тоже лишь 64 цветных элемента, но тем не менее с их помощью удается описывать классные картинки (заставка Гериона или тот же Робот - вообще шедевры) и делать симпатичные игры :) Все равно, что умудриться впихнуть игру в знакоместо 8x8 :)

Надо будет еще отчетик после конференции сюда скомпоновать :)