caxapa.ru :: так как это фундаментальная фича, то сделать тут вряд ли чего возможно. я просто хочу обратить внимание, что если где-то геммор уменьшился (квазинепрерывный аппаратный стек), то где-то он увеличился (переключение контекста)

yes (16.10.2008 15:00, просмотров: 225) ответил =AlexD= на Да тут скорее всего флушится всё окно, меняется указатель стека и попится с нового места. Вот и интересно, что они сделали для облегчения этого гемороя.

так как это фундаментальная фича, то сделать тут вряд ли чего возможно. я просто хочу обратить внимание, что если где-то геммор уменьшился (квазинепрерывный аппаратный стек), то где-то он увеличился (переключение контекста)

Ответить

- call-ы много чаще переключений (которые по таймеру). Цена потерь разная. - kpu(16.10.2008 16:10)
- Ну вообще то сделать можно. Можно в фоновом режиме, во время простоев шины скидывать регистры в стек, и помечать их как продублированные. =AlexD=(204 знак., 16.10.2008 15:08)
  - Для проца фона не бывает. Потенциально, любая следующая инструкция требует РОН. На halt(wait) расчитывать kpu(217 знак., 16.10.2008 16:07)
    - Я не понял, что Вы комментируете. На всякий случай - я про те регистры, которые не видны в текущем окне. Сохранять их во время обработки всяких mul add и п.р. регистровых операций, когда шина памяти не занята. =AlexD=(74 знак., 16.10.2008 17:57)
      - Стек машина(Си имею ввиду) развернулась, параллельно сохраняя в фоне регистры не видные в текущем окне. А потом свернулась. Вопрос: копирование регистров в память в данном случае будет происходить в пустую? - Yustas(21.10.2008 15:26)
        
        Разумеется. Вам известно понятие спекулятивное исполнение? Точнее понимаете ли вы что это такое? =AlexD=(870 знак., 21.10.2008 15:45)
        
        хм...предполагалось, что запас шины займет DMA.Для того и развит. Всерьез, kpu(118 знак., 21.10.2008 18:39)
        
        А что, ДМА пишет прямо в регистровый файл? Вообщето ДМА обычно льёт прямо в СДРАМ, минуя даже кеш. Иначе ступор на ровном месте вам обеспечен. =AlexD=(176 знак., 21.10.2008 18:47)
        
        Хотя нагляднее подсчитать число используемых регистров, и число АЛУшных команд. На большом наборе функций. - =AlexD=(21.10.2008 19:12)
        
        Эх..былоб так просто, функции то займут все что не дай, если не так, то сразу вывод:"функции плохо написаны" - kpu(21.10.2008 19:33)
        
        Ну при чём здесь всё это. У вас же есть готовый компилятор? Вот и включите листинг сделайте статистику. - =AlexD=(21.10.2008 20:04)
        
        ОК читайте так: "компилятор плохо написан". Да и задач не так много, kpu(59 знак., 22.10.2008 11:02)
        
        Йооо! Ну какой же я тупой!! У вас же симулятор есть!!! Подрихтовать его и компилятор и любую идею можно проверить за несколько дней. Тьфу, мля. - =AlexD=(21.10.2008 21:26)
        
        если вы про аккум, то дни это не про Си. Зря не писали раньше, НО kpu(202 знак., 22.10.2008 10:54)
        
        А не надо её завязывать в конвейер. Конвейер нужно тормозить только если команда пытается получить результат. И тут разницы нет, идёт ли чтение аккумулятора, или связанной с ним регистровой пары. =AlexD=(168 знак., 22.10.2008 11:09)
        
        "тормозить" спорно сразу, ибо лучше выполнить другие команды. Это RISC с DSPext. Есть другое DSP ядро,но пока только макетируется. kpu(123 знак., 22.10.2008 11:49)
        
        Ну тогда вам придётся городить ООО (внеочередное исполнение). Сразу скажу, что по сравнению с этим, мои скромные пожелания - это просто мелочёвка. :-))) - =AlexD=(22.10.2008 12:33)
        
        "внеочередное" уже есть, "мелочей" в архитектуре нет, все взаимосвязанно - kpu(22.10.2008 12:43)
        
        Значит я не понял в чём суть проблем. Ну да ладно. Разберётесь. - =AlexD=(22.10.2008 14:04)
        
        скорее всего, не "за такт", а "каждый такт". две большие разницы. - Mahagam(22.10.2008 11:11)
        
        согласен, согласен, но =AlexD=(82 знак., 22.10.2008 11:23)
        
        Тут компромис производительности и энергопотребления. Yustas(97 знак., 21.10.2008 16:30)
        
        Хех, так и думал, что про потребление услышу. Пока что у вас вообще ничего нет, и какое оно будет зависит от вас. Я вас удивлю, если скажу, что далеко не каждой embedded железяке вожно потребление? А для батарейных девайсов эту фичу можно сделать =AlexD=(118 знак., 22.10.2008 08:06)
      - "...во время обработки всяких mul add и п.р. регистровых операций..." - шины памяти занята: 5ти ступенчатый конвеер + буфер предварительный выборки инструкций. - Yustas(20.10.2008 20:04)
        
        Так у вас ещё и шина команд/данных одна??? "Я в шоке"(с) - =AlexD=(21.10.2008 13:03)
        
        не не, ядро чистый гарвард к кешам. Но (пока) контроллер памяти на одной шине с переферией. - kpu(21.10.2008 13:35)
        
        Уфф ,слава богу. :-) Ну периферия как память - обычное дело. - =AlexD=(21.10.2008 14:06)
      - а если вместо mul add будет ret rti? Сорри, kpu(103 знак., 17.10.2008 13:05)
        
        ну будет, и что? Отработает как полагается. В чём трудность? - =AlexD=(17.10.2008 13:08)
        
        чтоб отработало нужно где то взять контекст, а он в спилинге торчит kpu(475 знак., 17.10.2008 16:08)
        
        Нет, я никакого буфера не предлагал. И ничего ни в каком спилинге торчать не будет. Думайте ещё. - =AlexD=(18.10.2008 10:44)
        
        предлагали-предлагали :), и даже момент начала скидывания в память предлагали kpu(367 знак., 21.10.2008 16:10)
        
        Регистровый файл у вас уже есть, так что ничего нового не надо. =AlexD=(248 знак., 21.10.2008 18:37)
        
        ОК сдаюсь :), ваша идея разумная, НО только при частом флуше - kpu(21.10.2008 19:13)
        
        (занудно) :-) не столько при частом, сколько при неприемлимо длинном (RTOS). - =AlexD=(21.10.2008 19:18)

Микроконтроллеры