-
- скажу как практик использования спарков - использовать их для эмбедерства (когда нужен детерменированный отклик на прерывание) плохо. и тот же Гейслер (автор этого Атмела и вообще спарк гуру) рекомендует ставить не 32 "окна", а 8 или ыыыы(922 знак., 01.08.2011 14:40, )
- Идеал недостижим.Например, в моём дипломе был ADSP-2181. Так у него на каждый вектор прерывания отведено место на 4 команды. Коротенькие обработчики могут быть ещё короче. А если сделать место команд на 16 - так большего и желать почти не надо.У Точка опоры из дому(226 знак., 31.07.2011 13:56, )
- ну если у Вас все обработчики прерываний не длиннее 16 команд, то может Вам и пик10 или тини12 хватит - koyodza(31.07.2011 17:09)
- Не надо холиварничать. Ведь бывают и совсем коротенькие обработчики. - Точка опоры из дому(31.07.2011 22:31, )
- бывают. У меня сейчас из примерно 70 обработчиков 60 имеют минимально возможную длину 0 байт :=) - koyodza(31.07.2011 22:44)
- Кстати, хорошая была штука, позволяла сократить на один такт время выполнениякоротких обработчиков. Но смысл имела для ADSP с его расходами на прерываниев два такта. Для ARM с его расходами на прерывание в 26 тактов естественнобессмыслена. - Vallav_1(01.08.2011 08:01, )
- у армов (по крайней мере у СМ3) там не команды переходов на обработчики, а только адреса переходов - koyodza(01.08.2011 10:46)
- Кстати, хорошая была штука, позволяла сократить на один такт время выполнениякоротких обработчиков. Но смысл имела для ADSP с его расходами на прерываниев два такта. Для ARM с его расходами на прерывание в 26 тактов естественнобессмыслена. - Vallav_1(01.08.2011 08:01, )
- бывают. У меня сейчас из примерно 70 обработчиков 60 имеют минимально возможную длину 0 байт :=) - koyodza(31.07.2011 22:44)
- Не надо холиварничать. Ведь бывают и совсем коротенькие обработчики. - Точка опоры из дому(31.07.2011 22:31, )
- ну если у Вас все обработчики прерываний не длиннее 16 команд, то может Вам и пик10 или тини12 хватит - koyodza(31.07.2011 17:09)
- а почему Вы считаете, что "архитектура была бы для МК в самый раз, т.к. там много регистров"? Почему много регистров для МК - хорошо? Мне кажется, это весьма спорное утверждение, количество регистров никак не является определяющим - koyodza(31.07.2011 11:41)
- Должна быть золотая середина. Много регистров - это время, необходимое для переключения контекста. Я думаю, это не есть хорошо. - Bill(31.07.2011 11:54)
- Много регистров - всегда хорошо :), а контекст можно без крайней необходимости и не переключать. Ксения(108 знак., 31.07.2011 14:09)
- Это как?Создавать несколько вариантов функции с разными регистрами в качестве аргументов и локальных переменных и держать контекст - какой вариант сейчас исполняется? - Vallav_1(31.07.2011 17:55, )
- Когда время доступа к РОН и к SRAM одинаково, то большое кол-во регистров без особой пользы. Если конечно набор способов адресации при этом тоже одинаков. - rezident(31.07.2011 14:23)
- Дерьмо те РОНы, которые медленные, как SRAM. У SPARCа это, слава Богу, не так. - Ксения(31.07.2011 17:06 - 17:14)
- это дешёвые N локальных переменных, и дорогие N+1 и больше - koyodza(31.07.2011 14:13)
- А при малом числе регистров все локальные переменные одинаково дороги. - Ксения(31.07.2011 14:17)
- ключевое слово "одинаково" - koyodza(31.07.2011 14:38)
- А при малом числе регистров все локальные переменные одинаково дороги. - Ксения(31.07.2011 14:17)
- Много регистров - всегда хорошо :), а контекст можно без крайней необходимости и не переключать. Ксения(108 знак., 31.07.2011 14:09)
- Должна быть золотая середина. Много регистров - это время, необходимое для переключения контекста. Я думаю, это не есть хорошо. - Bill(31.07.2011 11:54)