caxapa.ru :: Ещё раз. Делая call со сдвигом проц ЖДЁТ пока выделяемые регистры сохранятся в стеке? ИЛИ КОГДА ЭТО ДЕЛАЕТСЯ (сохраняются регистры в стеке)?

=AlexD= (16.10.2008 12:36, просмотров: 114) ответил kpu на Всё наоборот проще. Спец команда это call,int,trap.

Ещё раз. Делая call со сдвигом проц ЖДЁТ пока выделяемые регистры сохранятся в стеке? ИЛИ КОГДА ЭТО ДЕЛАЕТСЯ (сохраняются регистры в стеке)?

Это моё личное предвзятое мнение. Любое совпадение с реальностью является случайным и непреднамеренным.

Ответить

- Когда 128 кончатся, тогда самый начальный(старый) call (его РОНы PC PSW) kpu(743 знак., 16.10.2008 13:45)
  - Вы всё время рассматриваете ситуацию, что у нас включили питание, и мы юзаем пустой регистровый файл. =AlexD=(367 знак., 16.10.2008 14:51)
    - идея оптимизации в том, что часто туда-сюда стек прыгает, то есть первые 20-30 call в линуксе дойдут до пользовательской программы, где call-ret-call-ret, это дает выигрышь (тот же спарк 5-10% у арма выигрывает), но за это сильно платить надо, когда yes(85 знак., 16.10.2008 14:58)
      - Понятно, если мы ёрзаем туда/сюда в пределах одного окна, то всё нормально, как только переключаем задачу, выясняется, что нам нужно сохранить 128 регистров. :-J Кстати, тут возможна аппаратная оптимизация. =AlexD=(36 знак., 16.10.2008 15:02)
        
        Не одного окна, а в пределах всего рег.файла (16 уровней). Про переключение, а по сути сначала про прерывания kpu(790 знак., 16.10.2008 15:50)
        
        как автоматом? через исключение и софтверную обработку? для прерываний это, имхо, опасно - там как раз должно быть минимальное окно, зарезервираванное в других процессах. для прерывания ведь latency - самое важное - yes(16.10.2008 20:21)
        
        Я так понял, что при прерывании делается тупо флуш всего регистрового файла :-( - =AlexD=(16.10.2008 20:44)
        
        Я неудачно написал (. Автоматом по общим правилам выделяется только kpu(461 знак., 17.10.2008 13:00)
        
        Да, я оговорился, всего файла ессно. В целом понятно, хотя могло быть и лучше. - =AlexD=(16.10.2008 17:55)
  - а как узнать в дальнюю дорогу проц ушел и сколько раз перекрутится стек? проблема в том - пусть есть многозадачная прога yes(405 знак., 16.10.2008 14:42)
    - Фокусов нет. В SWITCH TO TASK2 вставлен флуш, НО kpu(282 знак., 16.10.2008 15:58)
    - Да тут скорее всего флушится всё окно, меняется указатель стека и попится с нового места. Вот и интересно, что они сделали для облегчения этого гемороя. - =AlexD=(16.10.2008 14:54)
      - так как это фундаментальная фича, то сделать тут вряд ли чего возможно. я просто хочу обратить внимание, что если где-то геммор уменьшился (квазинепрерывный аппаратный стек), то где-то он увеличился (переключение контекста) - yes(16.10.2008 15:00)
        
        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)

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