caxapa.ru :: инспаред бай Z8 или SPARC? по опыту юзания спарка с кольцом РОН-ов можно недецки потрахаться. в то время как для простых задачек Z8 было суперб :). интересно программную модель компилера взглянуть (сори если просмотрел

yes (14.10.2008 18:47, просмотров: 42422) =AlexD=

инспаред бай Z8 или SPARC? по опыту юзания спарка с кольцом РОН-ов можно недецки потрахаться. в то время как для простых задачек Z8 было суперб :). интересно программную модель компилера взглянуть (сори если просмотрел - со вниманием беда в последнее время)

Ответить

- Вкратце особенность идеи следующая: Def(1035 знак., 15.10.2008 17:13)
  - про SPARC : проблема с сворачиванием разворачиванием квазинепрерывного стека, что требуется недетерминированое время на переключение (с прерываниями все не так - есть запас на одну задачку). поэтому хоть и окон в v8 может быть 32 (32*16+8=520 РОН) во yes(113 знак., 16.10.2008 14:35)
    - т.е. недетерминированность в рамках 136РОН допустима, а 520 уже не допустимо долго для реакции на прерывание? Возможно про это kpu(355 знак., 16.10.2008 16:40)
      - я не совсем точно написал - задержка детерминирована, просто сохранить 136 регистров быстрее чем 512. но это никак не касается ПРЕРЫВАНИЙ - они мгновенны (то есть для них одно окно всегда держится свободным) yes(469 знак., 16.10.2008 20:27)
        
        хмм, чтото у меня стойкое ощущение, что ребята наступили на все грабли, какие только можно. Например отдельный аккумулятор вне регистрового файла - просто пестня, как будто по другому сделать нельзя было. - =AlexD=(16.10.2008 20:42)
        
        Кроме эмоций, что Вы конкретно имеете ввиду ? Чем плох аккумулятор и есть ли что-то еще, что вызывает смущение и почему ? - Def(17.10.2008 10:27)
        
        Да просто могли бы уж его смапировать на, скажем, пару верхних или нижних регистров окна, раз уж у вас регистровый файл. =AlexD=(406 знак., 17.10.2008 10:55)
        
        Вероятно решений по сокращению количества "телодвижений" масса. Ваше - также одно из них, и, также не идеально, как и остальные. При проектировании основной акцент делается не на покрытии всевозможных "фенечек", а на компромиссе между сложностью Def(408 знак., 17.10.2008 14:00)
        
        Я сказал, что "у меня есть такое ощущение". У меня нет желания ковыряться в тонкостях вашей архитектуры, уже хотя бы потому, что она мне СОВЕРШЕННО не интересна. В ней нет ничего любопытного. Простая и тупая. =AlexD=(423 знак., 21.10.2008 11:47)
        
        "...того, что бросилось в глаза..." - пока только аккумулятор, что то еще? (Вопрос повторяется дважды) Yustas(533 знак., 21.10.2008 12:47)
        
        Я не предлагал терять РОНы - это одно из непониманий. Второе по ссылке. Действительно, с меня довольно препирательств с бандой маркетологов. - =AlexD=(21.10.2008 12:56, ссылка)
        
        Да, на счет теневых недопонял, коллеги ввели в курс дела. Yustas(348 знак., 21.10.2008 15:32)
        
        Ну вообще-то моё предложение несколько сложнее. И хитрее. =AlexD=(509 знак., 21.10.2008 16:01)
        
        Как сделать в железе не вопрос. Больше интересует суть усовершенствования. Yustas(222 знак., 21.10.2008 16:19)
        
        Да, всё так. Это позволит более свободно оперировать ДСП командами и компилятору, да и для неДСП задач может пригодиться. Одни плюсы, и ни одного минуса. - =AlexD=(21.10.2008 17:39)
        
        (повтор) а какое соглашение о вызовах компилеру? если писать на С, то "глобальный" аккумулятор вряд ли имеет смысл. а если он не виден компилеру и используется каким-то высокооптимизированным кодом вне функций - то это сильно геморно, но, возможно, yes(601 знак., 21.10.2008 16:35)
        
        соглашение по вызову: окно двигаем всегда на 8, r0 указатель Си стека, т.е. до 8-ми параметров в регистрах и 8-1 не портящихся РОН под функцию. kpu(118 знак., 22.10.2008 10:25)
        
        Ой как мутно... похоже ощущения меня таки не обманули. =AlexD=(81 знак., 22.10.2008 11:10)
        
        если нормально делать, то не быстрее - =AlexD=(21.10.2008 17:40)
        
        и главное дороже ибо еще производство, а не просто build и готово - kpu(21.10.2008 18:16)
        
        На сколько дороже? - =AlexD=(21.10.2008 18:39)
        
        10-100 экземпляров выразится в человекомесяцах, а серия просто несопоставимо kpu(14 знак., 21.10.2008 18:48)
        
        Я не понял расчётов. Обычно себестоимость считается от площади чипа и объёма выпуска. Или вы предлагаете архитектуру под заказ? Такое мне не нужно. - =AlexD=(21.10.2008 18:53)
        
        вот! "от объема выпуска". Есть фиксированные начальные затраты. Больше выпуск - меньше их доля в цене за чип. - kpu(21.10.2008 19:29)
        
        Извините, но доля стоимости пары человеко месяцев исчезающе мала во всех расходах на подготовку производства. Или физдизайн уже готов и испечена пробная партия? Тогда действительно поздно. - =AlexD=(21.10.2008 19:35)
        
        поздно для чего? ... от пробной еще осталось kpu(236 знак., 22.10.2008 10:33)
        
        думали над этим. Накладные (чтоб без противоречий) не оправдывали экономии - kpu(17.10.2008 13:09)
        
        Накладные чего? Вентилей? "кто экономит вентили, тот не пьёт шампанского" :-) - =AlexD=(17.10.2008 13:14)
        
        Не только этими "фенечками" определяется быстродействие проца. ++(262 знак., 20.10.2008 09:16)
        
        20..30 относительно чего, где конкретные цифры? Yustas(1441 знак., 20.10.2008 19:57)
        
        Можно где-нибудь скачать тесты (исходный текст, makefile) эффективности кэша, которыми Вы пользуетесь? ++(280 знак., 21.10.2008 11:27)
        
        Для профилировки использовался симулятор. - Yustas(21.10.2008 11:41)
        
        Злой, наверное, я стал в последнее время. Можете напр, запустить пару тестиков производительности cpu, fpu (по ссылке)? ++(897 знак., 22.10.2008 12:49, ссылка, ссылка)
        
        Такж, если знаете какие- нибудь интересные тесты пропускной способности памяти и эффективности кэша- огромная просьба: выложите ссылочку. ++(66 знак., 22.10.2008 13:01)
        
        На таких низких частотах и требования к кешу естественно ниже. - =AlexD=(21.10.2008 08:16)
        
        Как требования могут зависеть от частоты? - Yustas(21.10.2008 11:04)
        
        Чем выше частота проца, тем больше тактов тратится в холостую на ожидание памяти. Чем выше потоковая скорость памяти, тем больше латентности. Вообще то это азбучные истины. - =AlexD=(21.10.2008 11:10)
        
        Это понятно... Да, частота шины влияет на среднее время доступа, но _требования_ к кэшам выставляются отнюдь не азбучными истинами. - Yustas(21.10.2008 11:46)
        
        Ну да, ещё характером используемого ПО. Но поскольку это априори неизвестный фактор, дефакто требования к кэшу (объём и скорость доступа) определяются именно скоростью и латентностью памяти с одной стороны и частотой ядра с другой. - =AlexD=(21.10.2008 11:56)
        
        Согласен на 90%. Чем больше частота сpu относительно системной шины... ++(259 знак., 21.10.2008 11:34)
        
        Ну что вы, что вы, мы ж обсуждаем 200МГц проц, а не какой-нибудь Core 2 Duo. - =AlexD=(21.10.2008 11:57)
        
        Ну мы пока только ISA обсуждали, подсистема памяти и периферия - это отдельная песня. - =AlexD=(20.10.2008 12:56)
        
        Также вопрос: для чего все это обсуждение? ++(272 знак., 20.10.2008 09:35)
        
        Уважаемый, Вы постоянно подменяете понятия. Прошу Вас, да простят мои слова аксакалы к коим это не относиться, не пудрите людям мозги. Def(750 знак., 21.10.2008 14:51)
  - Правильно ли я понимаю =AlexD=(458 знак., 15.10.2008 19:08)
    - Всё наоборот проще. Спец команда это call,int,trap. kpu(481 знак., 16.10.2008 11:20)
      - Ещё раз. Делая 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)
- Если на asm- да. Зато в случае gcc, время личное, время процессорное и стек немного экономятся... - ++(15.10.2008 10:17)
  - btw : на ассемблере писать при готовом обработчике underflow/overflow вобщем-то проще, чем для ARM-а - yes(15.10.2008 15:26)
  - если gcc + RTOS, то переключение контекста вызывает вопросы (типа это че за хрень :) ) у тех, кто не знает архитектуру. Оптимизация под фиксированое число контекстов с управлением WIM вызывает немеряные потери личного времени :) я таки обломался yes(14 знак., 15.10.2008 15:23)
    - Вот это и не понятно, зачем что- то дописывать, если все уже написано до нас (напр QNX для sparc)? (Кроме доп аппаратуры Системы на кристалле, что решается BSP)? Улучшать порт RTOS, улучшать gcc? - ++(16.10.2008 10:22)
      - в последних gcc, например, исчезла поддержка flat моды, когда эти окна не крутятся. а проблему RTOS я попытался изложить выше и будь это хоть супер QNX для американских военных - контексту не прикажешь "раз-два сохранись" yes(207 знак., 16.10.2008 14:53)

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