ыыыы (22.08.2013 12:38, просмотров: 86) ответил =AlexD= на Да, я досконально разбирался с внутренней структурой, системой команд, более того, по моей просьбе проводили разработчики некоторые тесты. Я остался недоволен реализацией, хотя сама идеология очень перспективная.
да что там непривычного, погуглите DAG - тот же LLVM + graphiz рисует такие же картинки как и у них в доках (только покрасивше :). ну и вообще, к чему бы у всех архитектур, претендующих на производительность, трехоперандные инструкции? это же типа трата ПМ. то есть задачу оптимизации "параграфов" решают уже лет тридцать и какбы напридумывали много разного. те же out-of-order и register reordering|renaming все про это, опять же кеши: их управление (без ячеек памяти) жрет 2/3 кремния процессорного - к чему бы это?
по-поводу моей претензии: 1) в более детальном описании "коммутатора" отсутствует признак готовности (при этом работу датапаса обсасывают очень подробно - это по сути единственное, что тут можно запатентовать, и то может это мне кажется из-за малого знания лойерского аспекта), там и так асоциативная (CAM) память, возможно решили сократить, то есть я предположил, что эта готовность на весь мультилет
2) даже если добавить эту готовность - посмотрите, как на этих графах будет распространятся задержка
-------------
по поводу Ваших претензий
1) про прерывания в высокопроизводительной архитектуре речи нет, даже у "традиционного" TMS6xxx прерывания запрещены при исполнении оптимизированного кода
2) поэтому и попа с распределенными вычислителями, если бы туда вписывались кэши и вообще комон-дата, то пентиумы уже давно были бы на помойках. это все для потоковой обработки с детерминированым флоу (чтоб там они не писали в презенташках)
3) это САМ - почитайте как его делают - очень дорого добавлять дополнительные ячейки
4) я так подозреваю, что об "межпараграфной" оптимизации авторы вообще не думали
5) тут не разбирался - кажется, что для такой архитектуры это вообще невозможно, обычно выделяют отдельные целы для доступа к большой памяти - в эту архитектуру это не лезет
6) я так понимаю, что это происходит из-за задержек rd, если бы все rd были 1 такт (или даже известное N тактов) то даже самый тупой компилятор сумел бы генерить оптимальный код - вот это как раз проблема, которую и я не знаю как решать :)
7) 8) это я так понимаю для 4х ядерного, а что будет для 1024х :)
9) теоретически можно С компилер запилить и с кривым стеком, но это сильно трудоемчее, чем накодить целов и связей между ними :)