Что такое СТЕК и с чем его едят?, Знающим просьба пояснить простые истины...... Опции

[Potter]

Пять лет успешно программля на С. Пришло время.... Пришлось сталкнуться с ассеблером. Все понятно... Вот только не пойму я что такое СТЕК? Поясните пожалуйста особо популярно что это такое? Как он работает? И что в нем по обыкновению храниться? И почему без операций:

ldi r16, high(RAMEND)
out SPH, r16

ldi r16, low(RAMEND)
out SPL, r16

Конроллер МЕГА128 нормально не работает?

Заранее огромное спасибо.......

[defunct]

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

Какие сложности с постдекрементом SP? Не смешите тапочки.

Точно, молодцы - это чтобы разработчики компиляторов (типа gcc) не скучали . Куча разных схем в одном процессоре для разных стеков - это, наверное, очень весело . Имел в этом плане интересную беседу с Harry Zhurov'вым (автором вышеупомянутой RTOS), но переписка была личная, так что цитировать не имею полномочий.

Плохому танцору... все мы знаем что мешает.

[SasaVitebsk]

Соглашусь с defunct.

Ошибки в компиляторах и операционных системах были есть и будут. Это слабо зависит от реализации кристалла. К тому же сие вообще не показатель. Компиляторов для AVR - десяток, а программ миллионы.

А вот иногда, то что годами тащится по "совместимости" - это конкретная беда. То есть сначала - это разумный и единственно правильный шаг. Но время идёт, а человек не идеален и не может предусмотреть на годы вперёд. И вот с какого то момента самая прогрессивная архитектура, ОС, протокол или схемное решение является самым мощным тормозом.

Пример у всех на виду. ОС от WIN. Вместе с железом конечно и вместе с переферией. Только построение видюхи - медаль давать. На видюху выделено столько же памяти в адресном пространстве, сколько AT91SAM7S64 отводит на RS232.

Вот и получается, что достаточно слабый наладонник моего сына ACER n311 запускает эмуляцию MSDOS (!!!) из под неё запускает вторую кирандию и она вполне прилично работает!

[Dopler]

Прошу прощения, что невольно ввёл всех аврщиков в заблуждение, не хотел.

Ну, если обещаете, что больше так не будете


То, конечно, прощаем!!!

С Праздником всех!!!

[osnwt]

Плохому танцору... все мы знаем что мешает.

Я всего лишь привел пример того, что необоснованное отклонение от принятой в большинстве других популярных процессоров логики способно привести к применению "правила" по привычке, когда делаешь порт некоей системы под множество различных процессоров одновременно. Названная OS существует для процессоров от AVR до ARM7 и Blackfin, и не удивительно, что можно допустить механическую ошибку при внесении изменений в несколько портов параллельно.

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

Какие сложности с постдекрементом SP? Не смешите тапочки.

А Вы читать умеете? Я разве говорил о сложности? Я говорил о том, что механизм работы со стеком имеет существенное значение при работе с его указателем явно, а не посредством push/pop. Я не утверждал, что это как-то осложняет написание чего-либо. Я просто указал, что это вовсе не безразлично.

Соглашусь с defunct.

Все с чем-то соглашаются. Осталось еще определиться, с чем именно

Про ошибки повторяться не буду - уже было сказано.

А вот иногда, то что годами тащится по "совместимости" - это конкретная беда. То есть сначала - это разумный и единственно правильный шаг. Но время идёт, а человек не идеален и не может предусмотреть на годы вперёд. И вот с какого то момента самая прогрессивная архитектура, ОС, протокол или схемное решение является самым мощным тормозом.

Неужели я где-то высказался за то, что нужно тащить принятую архитектуру все время только из соображений совместимости?

Если говорить "в общем", то совместимость можно нарушить в тех случаях, если это дает реальный прогресс хоть в чем-то. В данном же конкретном случае я этого не вижу вообще.

А вот по логике работы схема в AVR куда более прозрачная и правильная чем у процессоров с пре-декрементом. Указатель стека всегда указывает на адрес действительной ячейки памяти а не на no-memory cell. Ведь физически нет такого адреса как RAMEND+1.
Каков смысл в предекременте, кроме как чтобы специально добавить дополнительный риск в программы.

Я не вижу никакой логики в приведенном высказывании.

Во первых, стек не обязан находиться в конце памяти до RAMEND, и выражение SP+1 может иметь физический смысл.

Во вторых, никого из программистов не смущает конструкция языка C *p++ при работе с массивом в цикле. При последней итерации значение указателя точно также выходит за пределы блока памяти, выделенного массиву, и не гарантируется физическое существование чего-либо за пределами этого блока. Что при этом не мешает использовать эту конструкцию программистам, ибо, пока мы не применяем операцию разименования к полученному p, проблем не будет.

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

Итого, выходит, что изменив "стандартную de-facto" логику, мы не получаем никаких видимых плюсов. Зато получаем в пределах одного процессора две различных системы организации стеков (SP и X/Y/Z), да еще и в пределах единого адресного пространства. Вот тут я вообще не вижу никакой внешней логики (про возможные внутренние оптимизации я говорил исходно, но это знают только разработчики архитектуры).

В целом, не имея желания кому-то что-то доказывать, я, тем не менее, свои соображения всегда аргументирую. Было бы интересно услышать конструктивную критику с фактами по пунктам, приведенным мною. Пока же я так и не увидел того, что положительного было внесено имплементацией двух схем работы со стеком в AVR. Ваши высказывания, уважаемые собеседники, пока лично меня не убедили в прогрессивности этого шага (что я аргументировал по пунктам). Потому пока остаюсь при своем мнении.