Привет!
Sat Sep 25 2004 19:59, Harry Zhurov wrote to Alexander Golov:
...
AG>> Hичего не мешает, кроме необходимого времени, тех самых 30 нс (или AG>> сколько там?), для доступа к памяти по новому адресу:
AG>> +-- здесь известен AG>> новый адрес AG>> | выборка add | выполнение add | v AG>> | выборка bra | выполнение bra | AG>> | выборка PC+1 | выборка по новому AG>> адресу |
HZ> -----------------------------------------^^^^^^^^
HZ> А почему бы не сделать в этом месте вместо "выборка PC+1" "выборка HZ> bra->> addr"? Адрес-то уже известен. Уж в случае безусловных переходов HZ> точно никаких принципиальных трудностей нет. Даже выяснять не надо HZ> (как в случае условного перехода), откуда следующую инструкцию фетчить.
В этом момент это не адрес, а абстрактный набор битов, адресом он станет лишь по завершению первого такта цикла, в котором осуществляется декодирование команды и станет известно, что это "bra". А подозрение в каждом выбранном последним наборе битов адреса безусловного перехода грозит тем, о чём я говорил в прошлый раз -- выбором каждой последующей команды за 2 цикла. Хотя на самом деле делать выборки по данным в полях команды без предварительного декодирования вообще нельзя.
...
AG>> Hет, для "любой другой команды" выбирается PC+1, а для goto адрес станет AG>> известен с момента начала её исполнения.
HZ> Для goto адрес известен после ее выборки.
Только не известно, что это goto, и что там адрес команды, а не, скажем, SFR'а.
...
AG>> Спор начался именно с того, когда я сказал, что PIC не декодирует AG>> предварительно выбранные команды (т.е. у него отсутствует AG>> процессинг-конвейер), а только задерживает исполнение первой команды на AG>> время выборки из памяти, общим случаем для которого выбран 1 цикл.
HZ> Hет. Спор начался, когда ты сказал, что переходы тривиальные, а я HZ> сказал, что это несколько не так, и именно из-за этого переходы и требуют HZ> дополнительных затрат либо в виде времени выполнения, либо в виде HZ> дополнительной аппаратуры. В этом и состоит нетривиальность.
Нет, мои слова относились к 2810 у которого из-за конвейера и вайт-стейтов переход тянет на 4...12 циклов, а здесь мы долго и нудно обсуждаем почему меня не смущает, что у PIC'ов переход длится 2 цикла; я описал почему (см. два абзаца выше).
...
AG>> Это не роскошь, а просто балласт. Создавать аппаратные навески для AG>> параллельного предварительного декодирования однословных безусловных AG>> переходов, чтобы в результате поднять производительность на 1% нет AG>> никакого смысла.
HZ> Производители DSP процессоров так не считают. Просто в МК это именно HZ> роскошь, они и так не претендуют на максимальное быстродействие, поэтому HZ> им не нужен такой наворот, увеличивающий стоимость и энергопотребление, HZ> бо автомат этот отнюдь не простой. Только и всего.
Не знаю, что там считают производители DSP, но у них оптимизация goto не будет обеспечивать существенного прироста производительности. А ускорение DSP-алгоритмов в этой части, куда эффективнее при создании специальных конструкций организации циклов, после чего переход выполняется даже не за 1, а за 0 циклов. Что мы и наблюдаем в dsPIC30F.
HZ> И потом, откуда ты взял 1%? Вот возьми какой-нибудь цикл, где HZ> три-четыре инструкции, одна из которых переход.
Близко к 100% -- условный. А мы говорим про безусловные, более того, только однословные, т.е. только bra, ещё возможно: rcall и return.
...
HZ> Это еще вопрос, кто чьи слова пересказывает. Hо не будем на это HZ> отвлекаться. Итак, ты по-прежнему утверждаешь, что единственная причина в HZ> медленности памяти.
Медленность -- причина, а всё остальное -- следствия конкретных путей преодоления связанных с ней проблем.
HZ> Я же утверждаю, что принципиальная причина не в HZ> медленности памяти, а в отсутствии в МК специальных аппаратных средств,
Для PIC'ов специальные аппаратные средства позволят разобраться лишь с однословными безусловными переходами.
HZ> наличие которых решает проблему - любой переход может быть выполнен за HZ> один цикл.
Чтобы разобраться с остальными переходами нужно строить абсолютно другой командный цикл с конвейерным декодированием и специальными аппаратными навесками смотрящими вперёд по конвейеру.
HZ> Пресловутая "медленность" памяти проблемой не является при HZ> желании.
Значит ни у кого нет желания, ибо все на этой памяти безбожно тормозят и единственный на всех способ преодоления -- кэш того или иного вида.
...
HZ> В заключение еще раз (последний): переход является тривиальным HZ> _ТОЛЬКО_ в случае, если оставить его как есть и получить потерю HZ> производительности.
Для PIC'ов переход это простое копирование адреса в PC и вставка одного nop. Единственное радикальное средство ускорения -- подкладывание полноразмерного скоростного ОЗУ под Flash и полное копирование кода перед запуском. Любые другие варианты работают в одних случаях и не работают в других, т.е. вносят дисперсию в результаты выполнения и в общем случае требуют закладываться на максимум.
...
HZ> И то, и другое и есть та HZ> самая _нетривиальность_, которую порождают тривиальные переходы.
Ну да, только вся "нетривиальность" наворотов у 2810 приводит к переходам даже без вайт-стейтов за 4/7 циклов, а "тревиальность" у PIC за 2 цикла в любых условиях.