|
|
Все ниже сказанное в основном основывается на опыте общения с 6х1х.
А как влияют на кэш команды переходов? По моему - никак, так как никакой системы предсказания переходов, а также очисток кеша по факту переходов и пред-выборки в этих семействах нет. Как я их кэширование понимаю (L1P), то команда перехода (в циклической структуре) только лишь уменьшает вероятность того, что строка кэша будет считаться устаревшей. То есть, при исполнении длинного линейного кода (особенно >размера кэша) будут cache-miss'ы на каждый fetch-packet. А при исполнении программы, состоящей из циклов с переходами между ними среднее количество промахов окажется несравненно меньше. Ведь 16кбайт L1P это на самом деле не так уж много, учитывая, что в качественно написанном коде среднее количество команд в execute packet 4-6. Конечно, L2 поможет. Но ведь не сильно - так как он экономит только лишь на ликвидации "лишних" тактов, требуемых для доступа во внешнюю память. Да и нет L2 в 6х0х. Так собственно вопрос - как могут переходы увеличить количество промахов (кэша программ)? ИМХО - они на это не влияют, так как не являются чем-то (с точки зрения кэша) отличным от других команд типа сложения или пересылки. Единственный известный мне минус (у переходов) - это возможность перехода в середину фетч-пакета, которая требует как-бы преждевременного fetch'а.
Теперь о самой оптимизации... software pipelinig накладывает очень серьезное ограничение - на это время должны быть запрещены прерывания, так как они "собьют" всю программную конвейеризацию. То есть, из-за необходимости их обслуживания, для большинства задач долго находиться в хорошо соптимизированном коде нельзя. Тут у меня есть такие пути -
а) накапливать данные в больших буферах (через EDMA), затем их обрабатывать.
б) писать код без прерываний, запараллеливая прием данных в общую кучу.
в) на время прерываний (если они не слишком часты) стопорить кэш, а сам код прерывания располагать в L2, а не в SDRAM.
У каждого есть куча недостатков. Основные: у а) далеко не всегда можно себе позволить задержку. у б) куча откровенно говоря программистского геморроя. И у в) нельзя себе позволить что-то посложнее в прерывании - затормозит весь процесс. Конечно, в каждом случае что-то выбираешь свое, часто какой-то компромисс между "идеальностью" оптимизации и скоростью написания программы. Но все-же очень хотелось бы знать, как для достижения тех-же целей поступают другие. Чем жертвуют, может быть какие-то интересные решения (в теории).
E-mail: 
info@telesys.ru
