![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vakДополнение про украинский суперкомпьютер от Сергея Колисныка, на языке оригинала.
"Вони демонстрували симулятор. Звичайний симулятор-debugger, як для будь-якої архітектури. Вікно вихідного коду, даних, машинного коду. Мене дивувало, що за доволі традиційної (з точки зору 1960х) архітектури обчислювального модуля (так, у них жорсткий обчислювальний елемент) відсутній асемблер з мнемоніками - відображається лише цифровий машинний код. Отже, кожен процесор - звичайний, здається, гарвардський (мені казали точно, але я забув). На питання про асемблер казали, що їхній Паскаль і є замість асемблера (звісно, я згадав Ельбрус, але ж там був і звичайний мнемонічний асемблер). Але машинні коди досить традиційні. Особливість - АЛП комплексний з фіксованою комою."
"Вони демонстрували симулятор. Звичайний симулятор-debugger, як для будь-якої архітектури. Вікно вихідного коду, даних, машинного коду. Мене дивувало, що за доволі традиційної (з точки зору 1960х) архітектури обчислювального модуля (так, у них жорсткий обчислювальний елемент) відсутній асемблер з мнемоніками - відображається лише цифровий машинний код. Отже, кожен процесор - звичайний, здається, гарвардський (мені казали точно, але я забув). На питання про асемблер казали, що їхній Паскаль і є замість асемблера (звісно, я згадав Ельбрус, але ж там був і звичайний мнемонічний асемблер). Але машинні коди досить традиційні. Особливість - АЛП комплексний з фіксованою комою."
no subject
Date: 2013-11-12 20:14 (UTC)no subject
Date: 2013-11-12 20:19 (UTC)no subject
Date: 2013-11-12 20:30 (UTC)Собственно, и даже отвлекшись от вопросов совместимости процессоров, проблема классического VLIW очевидна - дофигища пропускной способности памяти будет уходить на выборку команд.
А кстати, вот и идея, как преодолеть эту проблему: сжимать последовательные участки программы чем-нибудь типа Зипа. И даже куски с большим числом переходов можно сжимать одним блоком и внутри блока делать переходы на расжатые адреса, держа весь блок временно расжатым. При нынешнем развитии железа засунуть разжималку в железо должно быть нетрудно.
no subject
Date: 2013-11-12 21:28 (UTC)no subject
Date: 2013-11-12 22:44 (UTC)no subject
Date: 2013-11-12 23:03 (UTC)А про Интел - ну да, я и думаю, что этот подход оказался более выгодным, чем VLIW, потому VLIW никто в итоге и не использовал.
Кстати, другая проблема VLIW - небось, в комбинировании условных переходов и загрузки вычислительных элементов. Интельный подход позволяет загружать вычислительные элементы динамически, в соответствии с вычисленными до того переходами. А во VLIW они получаются жестко привязаны друг к другу на этапе компиляции, и переходы становятся барьерами для загрузки логических элементов. И это наверное причина того, что в IA64 изначальный VLIW превратился в систему формулирования последовательных кусочков, собираемых вместе практически через dataflow graph.
В-общем херня получается этот украинский "суперкомпьютер" :-)
no subject
Date: 2013-11-12 23:10 (UTC)no subject
Date: 2013-11-12 23:28 (UTC)no subject
Date: 2013-11-13 00:06 (UTC)no subject
Date: 2013-11-13 00:29 (UTC)no subject
Date: 2013-11-13 02:42 (UTC)no subject
Date: 2013-11-13 02:51 (UTC)no subject
Date: 2013-11-13 02:53 (UTC)no subject
Date: 2013-11-13 03:00 (UTC)Посмотрел thumb - это существенно другое, уменьшенное подмножество команд. У честного VLIW команды будут в 4 раза длиннее, чем у RISC, так что выгода в компрессии должна быть.
no subject
Date: 2013-11-13 03:03 (UTC)no subject
Date: 2013-11-13 03:04 (UTC)no subject
Date: 2013-11-13 03:17 (UTC)for(....) { do something; }
for(....) { do something completely different; }
Отлично можно скомпилировать в два микротреда автоматически.
no subject
Date: 2013-11-13 03:20 (UTC)no subject
Date: 2013-11-13 03:30 (UTC)no subject
Date: 2013-11-13 03:35 (UTC)no subject
Date: 2013-11-13 06:53 (UTC);)
no subject
Date: 2013-11-13 08:22 (UTC)А еще мне череп замеряли и нашли еврейские корни.
no subject
Date: 2013-11-13 12:35 (UTC)no subject
Date: 2013-11-13 12:40 (UTC)no subject
Date: 2013-11-13 15:57 (UTC)no subject
Date: 2013-11-13 16:04 (UTC)no subject
Date: 2013-11-13 16:07 (UTC)no subject
Date: 2013-11-13 16:13 (UTC)это проверялось практикой.
> PDP-11 приходилось прибегать к подпрограммам csv/cret.
чё?
no subject
Date: 2013-11-13 16:56 (UTC)На 32-разрядной PDP-11 проверьте.
чё?
Ничё. Учите матчасть, например:
Си-компилятором на PDP-11 пользовались? В ассемблер смотрели?
no subject
Date: 2013-11-13 17:12 (UTC)8086/80286 были точно так же 16-разрядными.
плотность кода с тех времен у уинтела не увеличилась.
> Си-компилятором на PDP-11 пользовались? В ассемблер смотрели?
ну. только все же наоборот: поскольку на pdp-11 такой трюк провернуть было можно, то все регистры сохранялись одной однословной коммандой, а на интеле надо было каждый раз использовать последовательность индивидуальных комманд, что выходило длинее.
no subject
Date: 2013-11-13 17:32 (UTC)http://www.researchgate.net/publication/224114307_Code_density_concerns_for_new_architectures/file/32bfe5118fd8e27899.pdf
И где там "3 раза"?
no subject
Date: 2013-11-13 19:08 (UTC)с ваксом я уже не сравнивал
no subject
Date: 2013-11-13 19:32 (UTC)Они там пишут, что интеловский код от компилятора можно вручную ужать примерно вдвое. Мы знаем, что пидипишный код генерировался тоже очень рыхлый; возможно, его можно было бы ужать еще сильнее, и в результате аналогичный пидипишный код мог бы быть на пару десятков процентов меньше.
Но кого бы это в реальной жизни интересовало? Львиную долю времени процессор выполняет команды, порожденные компиляторами.
no subject
Date: 2013-11-13 19:43 (UTC)мы сравнивали ручной ассемблерный код.
оптимизацией генерации пидпишного кода с языков типа си никто не занимается уже больше 20 лет. в отличии от интела. что не влияет на их взаимную рыхлось.
no subject
Date: 2013-11-13 21:52 (UTC)no subject
Date: 2013-11-13 22:09 (UTC)