Свой эмулятор работает нормально, но хотелось бы прикрутить к нему сабж. Хочется посмотреть отличия в поведении кода на процессорах с конвеерами различной длины. Собственно трудности с алгоритмом предсказания ветвлений кода.
А что это даст в принципе? Теоретически наверное возможно сэмулировать конвеер, по крайней мере для любого конкретного проца. Непонятна цель.
1) Сейчас учавствую в проекте (уже больше 10 лет), он немного мне уже надоел, но его необходимо закончить, так как помимо всего прочего большие премиальные. В ходе проекта создана железяка: Разрядность 512 бит, 8 наборов по 6 РОН, 133 МГц частота. Програмная память 128 Мб, память данных 20 Гб. Плюс куча дополнительных сопроцесоров для разных видов вычислений. Для полного решения задачи необходимо железяку ускорить. Поднять частоту невозможно по техническим причинам. Разрядность будем удваивать, но пока плиски застряли на таможне. Плюс возникла идея добавить нормальный конвеер. Со структурой конвеера П6 примерно разобрался (основная сложность алгоритм динамического предсказания ветвлений). Не могу найти инфу по конвеерам АМД (вроде как круче чем у интела) и последним интелам (голова уже кругом идет, скорее всего просто под носом не вижу). А чтобы это все прошить в железо нужно предварительно погонять на эмуляторе, т.к. железяка одна и даже недоведенная зарабатывает деньги и долго простаивать ей нельзя. А второй экземпляр для опытов сделать затруднительно так как я физически далеко, и надолго приехать для проведения нужных экспериментов не могу, а домой его мне никто не вышлет. 2) Если нормально получится с х86/х64 процами, есть мысли доработать борщ.
zicker там же команды разбиваются на микрооперации и по этому делу наврятли что в паблике есть. пременова РОНов и дочерта всего другого. это в каком-то смысле комерческая тайна.
Плохо, хотя по выводам сделанным из косвенной информации коммерческая тайна не такая уже и тайна. Все равно один в один микрокоды не повторишь (( Придется наверное велосипед придумывать, как борщ доработать под РС уже придумал, осталось время выделить закодить. А себе придется конвеер П6 дотачивать. Хотя может быть хоть какое-то описалово К8 найду.
zicker А чего его искать? На оф. ресурсе его только что разобраным не нарисовали. Еще, конечно, Агнер Фог, как же без него. А вообще муторно это. Тайна - не тайна, только на Core 2 и выше даже pipeline нигде не нарисован, догадывайтесь сами. Наверное, это никому особо не нужно, как тот неуловимый Джо. У меня как-то была подобная идея, но застрял уже на этапе сбора информации. А потом поперли ваще непредсказуемые монстры, типа того же Core2 и я плюнул. Тут у мя как раз по работе бяка - даже уважаемые продукты (не буду показывать пальцем) какой-то паршивый RISC адекватно сэмулировать не могут... тьху.
zicker Подробное описание стадий конвеера AMD есть только в "древнем" мануале по оптимизации Athlon (K7) от 2002 г (№22007). В последующих же мануальчиках для К8 и К10 приведены только структурные схемы процессора и отдельных юнитов, из которых можно получить только какие-то общие и\или отрывочные представления о числе стадий. Например, для К8 на картинках показано число стадий фетча и декодирования, а для K10 уже нет Та же картина и у Intel - есть (хотя и не такое подробное) описание стадий конвеера первых P6 и P4, и практически ничего, кроме примерного числа стадий, для P4E, PM и Core. Хотя в рамках одной архитектуры общая структура конвеера остается той-же и лишь увеличивается дробление основных стадий на подстадии
Толи я чего то не понимаю. Но по моему у Intel весь конвеер описан. Да и предсказание условных переходов тоже описано. Еще есть патенты. Можно по их описаниям понять что к чему.
На интел описание я нашел и понял. АМД немного по другому поступило, у них на меньшей частоте выше производительность. А в патентах поискать из головы вылетело. Все равно допиливать под себя нужно, так как по архитектуре мой монстрик ближе к х80 (а конкретней z80 - был взят за основу), чем х86/х64. При моих задачах выгоднее ипользовать несколько статических наборов правил, чем использовать динамический алгоритм.
Если вы вручную(полу автоматически) будете оптимизировать. То это у вас займет еще лет 10. А вот если у вас плохой код то тут лучше динамика. Были у меня и другие мысли по которым пришел к выводу что в большинстве(во всех) случаев динамика лучше статике.
Код не плохой, просто одинаковый. Хотя скорее всего Вы правы, за то время пока соберется статистика быстрее реализовать динамический алгоритм, с сохранением результатов.