Покидаю-ка я сюда разные мысли насчёт системы команд вычислителя будущего.

[thesz]

Comments

[nicka_startcev]

А почему за основу выбран регистрово-стековый процессор, а не чисто стековый?

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

[nealar]

У стека голова одна, как мы будем параллелить вычисления на несколько процессорных ядер? Которых может быть более-менее любое количество

[nicka_startcev]

Параллелить - явно и вручную, на этапе компиляции.

Компилятор - он заведомо умнее и прозорливее процессора, ибо знает весь контекст и, в принципе, ему можно всякие хинты давать.

Если алгоритм в принципе параллелится, его лучше распараллелить на этапе написания/компиляции, а не на этапе исполнения.

ps: интересно, а чисто стековый vliw бывает? :)

[nealar]

Параллелить - явно и вручную, на этапе компиляции.
Предлагаю начать параллелить прям щаз. Как несколько ядер будут доступать к одному стеку?

[nicka_startcev]

Никак. Оно и сейчас никак. Или настолько криво, что выигрыша практически нет.

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

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

А почему жизнь такая нехорошая - это отдельная тема про врожденные уродства системы команд х86 и методы ее преодоления грубой силой а-ля пень-4.

[thesz]

>сделав несколько независимых потоков, которые общаются в заранее известных документированных местах, чтоб процессору не приходилось угадывать, что можно, а что нельзя спаривать.

Так и будет.

[nealar]

И тема плавно съехала от неприменимости стековой архитектуры к x86-флэйму. :)

[thesz]

Регистрово-стековая машина всё ещё содержит стек.

Но у меня нет задачи сделать параллельные вычисления на уровне программы узла (той, что оперирует ключами и той, у которой программа 16-64 байт).

Поэтому стековая архитектура здесь вполне применима.

Я её ещё доточу. ;)

[nealar]

У тебя модуль, который лазает во внешнюю память, и кормит остальных данными, всегда один? Если да, то можно и стековую.

[thesz]

Там, где регистрово-стековая машина, там нет модулей, которые "лазают во внешнюю память".

Регистрово-стековый код появляется в виде обработчика сообщения и может породить сообщения.

[nicka_startcev]

Ага. Причём, непонятно, кто защищает х86. :)

[nealar]

Я могу позащищать, кроме тех мест, где оно действительно кривое. Да и в них, наверное, тоже могу, не пробовал. :) Но здесь лень, тема о другом.

[thesz]

Размер код вычислительного узла - 16-64 байт. Память вон выше - примерно 12 основных и 4 дополнительных 32битных слова.

Память надо адресовать напрямую.

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

Хочу отметить, что большая программа на Си будет побита на множество мелких программ для регистрово-стековой машины, общающихся между собой с помощью сообщений.

Поэтому никаких вызываемых функций, никакого контекста выполнения, вообще ничего такого.

Воспринимайте это, как микрокод, но который напрямую не может адресоваться к памяти.

[nicka_startcev]

>Размер код вычислительного узла - 16-64 байт. Память вон выше - примерно 12 основных и 4 дополнительных 32битных слова.

Ясно. А, например, длинный непараллелящийся алгоритм как ляжет на эту архитектуру?
Разобъётся на стадии и трансформируется в нечто типа "потокового вычислителя" с стопицот коротких стадий?

(микро)коды в вычислителях фиксированные, или их можно перезагружать? Насколько быстро?

Если одна операция в вычислителе (условно) занимает один такт, то сколько тактов будет задержка между выдачей сообщения одним вычислителем и началом ее обработки другим? Не будет ли тут очень нехорошей латентности, как у того же пень-4, у которого ошибки предсказания стоили крайне дорого?

ps: интересно, а можно ли текст обычной программы на обычном си скомпилировать сразу в vhdl? :)
pps: видел где-то описание забавного форт-процессора -- дофига микроскопических ядер, у каждого ядра порядка 64 байт адресуемой памяти.

[thesz]

>Ясно. А, например, длинный непараллелящийся алгоритм как ляжет на эту архитектуру

[nicka_startcev]

да. если размер код вычислительного узла - 16-64 инструкций, то PC может быть 6-битным, а не 32.