caxapa.ru :: Всё наоборот проще. Спец команда это call,int,trap.

kpu (16.10.2008 11:20, просмотров: 101) ответил =AlexD= на Правильно ли я понимаю

Всё наоборот проще. Спец команда это call,int,trap. Перед call задается сколько регистров сохранить (на сколько двинуть окно), любая процедура получает свои регистры иниченные только параметрами. Конечно, имея 128 регистров хочется всего и сразу, но как заметили выше тогда полный гемор на протяжении всех процедур следить за их распределением, а так поставил сдвиг и делай call-ы квазибесконечно :). Выходит в Орхидеи средний вариант. Относительно традиционных push/pop экономия, относительно упомянутых Z8, SPARC автоматизация.

Ответить

- Ещё раз. Делая call со сдвигом проц ЖДЁТ пока выделяемые регистры сохранятся в стеке? ИЛИ КОГДА ЭТО ДЕЛАЕТСЯ (сохраняются регистры в стеке)? - =AlexD=(16.10.2008 12:36)
  - Когда 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)

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