Вопросы по С/С++ (СИ)

[VladislavS]

Согласен, такую реализацию можно считать двумя стеками. Я думаю, это для совместимости с амёбами с фиксированным аппаратным стеком.

[ARV]

если брать IAR, то разве он для младшеньких PIC-ов существует? а аппаратный стек вроде как больше нигде не присутствует... по-моему, еще у AT90S1200 или какого-то подобного "безОЗУшного"... ну так для таких "амеб" и Си применять - верх безрассудства. как-то странно все это...

[VladislavS]

Честно говоря, про амёб уже плохо помню, AVR-ки только на сопровождении старых проектов остались. Так то доводов в пользу такого подхода много можно придумать. Например, оптимизиция может лучше работать. Но это только программеры из IAR нам смогут рассказать.

[ПростоНуб]

Могу предположить, что это имеет смысл для архитектур памяти, подобных 16-битному режиму x86, в котором один сегмент стека не может превышать 64К. Тогда два сегмента удваивают этот лимит.

[ARV]

я могу предположить много чего, но как эти сегменты увязаны с IAR для AVR или CodeVision?!

[VladislavS]

Да никак. По умолчанию тихо мирно рядом лежат. При необходимости их можно легко растащить по разным сегментам памяти. Заподозрить IAR-овцев в некомпетентности трудно. Сделали так, значит так лучше. Может так удобней для их "stack usage analysis", например.

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3583992#p3583992"]я могу предположить много чего, но как эти сегменты увязаны с IAR для AVR или CodeVision?![/uquote]
Да никак. Какой смысл писать отдельные продукты для разных архитектур, если можно иметь общий продукт и разные только кодогенераторы? Если желательно иметь такое разделение стеков для того же CompactRISC (CR16C), то какой смысл ограничивать данный функционал только этой архитектурой?

[VladislavS]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3584046#p3584046"]Какой смысл писать отдельные продукты для разных архитектур,[/uquote]Ну это вообще не довод. IAR поддерживает множество архитектур и ко всем с одним подходом нельзя. Только на ARM я видел от одного до пяти стеков на разных ядрах.

[ПростоНуб]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3584051#p3584051"][uquote="ПростоНуб",url="/forum/viewtopic.php?p=3584046#p3584046"]Какой смысл писать отдельные продукты для разных архитектур,[/uquote]Ну это вообще не довод[/uquote]
Ядро Linux тоже поддерживает множество архитектур, но является единым продуктом.
Тоже самое можно сказать про LLVM, GCC, SDCC и т.п.
Кодогенераторы для разных архитектур, естественно разные, но ряд опций, имеющих смысл для одной архитектуры могут не иметь никакого смысла для другой. И это нормально.

P.S. Поймите, это не довод - это факт. Кроссплатформенный программный продукт всегда имеет общую кодовую базу и минимум различий, специфичных для разных платформ. Это в разы удешевляет поддержку такого продукта.

[ARV]

я, конечно, не специалист, но с моей профанской точки зрения использование отдельного стека для архитектуры типа AVR очень нерационально: там всего 3 регистровых пары, успользующихся для указателей, и резервирование одной под указатель стека данных - это -30% потенциальной эффективности, имхо.

[ПростоНуб]

Так Вас же никто не заставляет. Если у Вас в коде есть динамические стековые переменные, то разные указатели стека существенно упростят отладку. Например, на x86 в GCC есть такой интересный параметр, как -fomit-frame-pointer/-fno-omit-frame-pointer, который управляет тем, будут ли локальные переменные адресоваться через ESP или EBP. В первом случае получается код удобный для отладки, во втором - более компактный и оптимальный.

[ARV]

на x86 в GCC есть такой интересный параметр

какое это имеет отношение к моему вопросу?

вопрос в контексте микроконтроллеров, у которых нет "разных" ОЗУ и нет защиты блоков ОЗУ от доступа "чужих" процессов

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3584140#p3584140"]

на x86 в GCC есть такой интересный параметр

какое это имеет отношение к моему вопросу? [/uquote]

там всего 3 регистровых пары, успользующихся для указателей, и резервирование одной под указатель стека данных - это -30% потенциальной эффективности

В x86 тоже всего три регистра для указателей (EBP,ESI и EDI), но при этом потеря одного из них считается оправданной для упрощения отладки. Почему это не так для AVR?

[VladislavS]

Отладка на AVR? Нет, сынок, это фантастика!

[ARV]

Отладка на AVR? Нет, сынок, это фантастика!

ваша ирония неуместна. протеус для отладки AVR - самое оно вообще бесплатно

(EBP,ESI и EDI), но при этом потеря одного из них считается оправданной для упрощения отладки

вообще говоря, я уже точно не помню, но вроде EBP (BP) изначально предназначен для работе в сегменте стека с локальными переменными, и как раз отказ от его такого назначения делается (вероятно) в угоду какой-то оптимизации, а не наоборот.

что касается AVR, то вопрос был не об оптимизации или её отсутствии, а о выделение под данные отдельного стека. по тем картинкам, что я приводил, видно, что это никак не связано с уровнем оптимизации или отладкой.

я скорее соглашусь, что это сделано "по традиции", как было высказано ранее, чем ради улучшения отладки.

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3584226#p3584226"]

(EBP,ESI и EDI), но при этом потеря одного из них считается оправданной для упрощения отладки

EBP (BP) изначально предназначен для работе в сегменте стека[/uquote]
Где я писал про BP? И о каких сегментах Вы ведете речь применительно к 32/64 разрядному регистру EBP?

как раз отказ от его такого назначения делается (вероятно) в угоду какой-то оптимизации

Именно так, потому что при адресации через указатель стека, который гуляет произвольным образом во время работы отлаживаемой функции, только компилятор помнит, где же относительно него расположена та или иная переменная.

я скорее соглашусь, что это сделано "по традиции", как было высказано ранее, чем ради улучшения отладки.

А это уже Ваше дело. Но отлаживать код JTAGICE mkii с двумя стеками будет существенно проще.
Хотя свое мнение я уже высказал выше:

Если желательно иметь такое разделение стеков для того же CompactRISC (CR16C), то какой смысл ограничивать данный функционал только этой архитектурой?

[ARV]

о каких сегментах Вы ведете речь применительно к 32/64 разрядному регистру EBP?

мда... архитектура x86, если вы вдруг не в курсе, начинается с времен 16-разрядных регистров BP/SP/EI/DI/AX и т.п. и вкупе с сегментными регистрами CS,DS и т.п. а буковку E к ним прилепили позже, "забыв" про сегменты. но термин "сегмент стека", по-моему, еще не умер, хотя теперь подразумевает просто область памяти...

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3584516#p3584516"]

о каких сегментах Вы ведете речь применительно к 32/64 разрядному регистру EBP?

мда... архитектура x86, если вы вдруг не в курсе, начинается с времен 16-разрядных регистров[/uquote]
ARV, не тупите и перечитайте тему. Речь шла о параметре -fomit-frame-pointer, который к 16-ти разрядным архитектурам не имеет вообще никакого отношения и влияет только на стратегию использования регистра EBP компилятором.

[ARV]

я вообще спрашивал о микроконтроллерах... и к чему вы перескочили на какие-то абсолютно НЕ ТЕ платформы, и что этим хотите доказать - для меня остается загадкой. с архитектурой x86 я знаком, и вопросы про целесообразность стека данных для этой архитектуры не задаю.

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3584607#p3584607"]я вообще спрашивал о микроконтроллерах... и к чему вы перескочили на какие-то абсолютно НЕ ТЕ платформы, и что этим хотите доказать[/uquote]
Я уже писал это выше дважды! Раз на "не тех" платформах оправдано резервирование одного регистра из трех под нужнды отладки, то почему это не может быть оправдано на МК?