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

[Potter]

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

ldi r16, high(RAMEND)
out SPH, r16

ldi r16, low(RAMEND)
out SPL, r16

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

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

[rezident]

Стек (Stack) в переводе "палка". В применении к аппаратно-программной части микроконтроллеров это линейная часть ОЗУ, выделенная для хранения данных по принципу LIFO (Last In - First Out) Последним Вошел - Первым Вышел. Стек нужен для организации работы прерываний и подпрограмм/функций. В стеке могут хранится, как уже указал Alex B._, адреса возврата из функции/прерывания, данные для передачи параметров в/из функцию, буфер(а) для локальных переменных. Прерывания используют стек на аппаратном уровне как минимум для записи текущего адреса выполняемой программы (некоторые сохраняют в стек еще и слово состояния АЛУ ядра МК и пр.), чтобы после обработки прерывания, можно было вернуться и продолжить ее выполнение. Поэтому. если вы заранее не установили указатель стека на свободную часть ОЗУ, то при вызове прерываний последовательность выполнения программы может быть нарушена. В отличие от счетчика команд, который работает с автоинкрементом, то указатель стека работает с автодекрементом. Поэтому указателю стека обычно присваивают значение адреса не начала, а конца ОЗУ. Напротив, глобальные переменные и "куча", используемые в Си, располагаются с начала ОЗУ. Поэтому эти две области данных "растут" навстречу друг другу. Переполнение стека, при котором содержимое стека "наползает" на область глобальных переменных и/или "кучи", это одна из самых типичных и в то же время весьма трудно обнаруживаемая ошибка, возникающих при программировании МК.
Есть еще другие понятия стека, например, "стек протоколов". За разъяснениями можно обратиться к Википедии, например.

[=GM=]

Стек (Stack) в переводе "палка"

Отличное объяснение. Перевод только немного надо подправить: стек (stack) в переводе означает "скирда, стог; кипа" (а палка это stick).

Для образности ещё добавлю, что стек можно представить себе в виде автоматного магазина, патроны вставляются последовательно 1-2-3-4-5..., а вынимаются ...5-4-3-2-1.

А вот в нижеприведенном фрагменте теряется безвозвратно один байт ОЗУ.

Код

     ldi   r16,high(RAMEND)
     out   SPH,r16
     ldi   r16,low(RAMEND)
     out   SPL,r16

Надо бы писать так

Код

     ldi   r16,high(RAMEND+1)
     out   SPH,r16
     ldi   r16,low(RAMEND+1)
     out   SPL,r16

Кто бы мне объяснил, почему так не делают? Инерция мышления?

[Dopler]

Стек (Stack) в переводе "палка"

Отличное объяснение. Перевод только немного надо подправить: стек (stack) в переводе означает "скирда, стог; кипа" (а палка это stick).

Для образности ещё добавлю, что стек можно представить себе в виде автоматного магазина, патроны вставляются последовательно 1-2-3-4-5..., а вынимаются ...5-4-3-2-1.

А вот в нижеприведенном фрагменте теряется безвозвратно один байт ОЗУ.

Код

     ldi   r16,high(RAMEND)
     out   SPH,r16
     ldi   r16,low(RAMEND)
     out   SPL,r16

Надо бы писать так

Код

     ldi   r16,high(RAMEND+1)
     out   SPH,r16
     ldi   r16,low(RAMEND+1)
     out   SPL,r16

Кто бы мне объяснил, почему так не делают? Инерция мышления?

Господин GM, зачем вводите в заблуждение и так не окрепшие умы инженеров.
Предложенная вами инициализация стека совершенно не правильна и работать не будет.
Предлагаю вам обратить внимание на команду push

This instruction stores the contents of register Rr on the STACK. The stack pointer is post-decremented by 1 after the PUSH.

А так же предлагаю вам просимулировать в студии код:

Код

; Ваш код
RESET:

    ldi     tmp,    high(RAMEND+1); Main program start
    out     SPH,    tmp; Set stack pointer to top of RAM
    ldi     tmp,    low(RAMEND+1)
    out     SPL,    tmp

    clr        zero

    push    zero

; Правильный код
RESET:

    ldi     tmp,    high(RAMEND); Main program start
    out     SPH,    tmp; Set stack pointer to top of RAM
    ldi     tmp,    low(RAMEND)
    out     SPL,    tmp

    clr        zero

    push    zero

[=GM=]

Господин GM, зачем вводите в заблуждение и так не окрепшие умы инженеров.

Прошу прощения, что невольно ввёл всех аврщиков в заблуждение, не хотел. Вообще, если честно, я и не предлагал так делать, просто просил объяснить мне, почему так не делают. Вот, кстати, посмотрел старые проекты с авр на борту, там исходный указатель указывает на последнюю ячейку памяти.

А пошло это, скорее всего, вот откуда. Недавно интенсивно работал с TMS320C5402, надо было реанимировать старый проект, а там для push как раз предекремент стека, вот видимо и отложилось в голове, другого объяснения нет.

Ну и, с праздником всех!

[osnwt]

А пошло это, скорее всего, вот откуда. Недавно интенсивно работал с TMS320C5402, надо было реанимировать старый проект, а там для push как раз предекремент стека, вот видимо и отложилось в голове, другого объяснения нет.

В большинстве архитектур, с которыми мне приходилось сталкиваться, действительно используется предекрементная схема (в классической системе команд PDP-11 применяемая как MOV R1, -(SP) для push, MOV (SP)+, R1 для pop. AVR в этом плане действительно извращенно реализован. Видимо, к тому были какие-то аппаратные предпосылки. Например, проще поместить в память по адресу указателя байт, а потом параллельно с выборкой следующей инструкции уже декрементировать указатель стека. Но это только версия, а на деле имеем то, что имеем - такой подарок писателям RTOS-ов под AVR :-)

[defunct]

Но это только версия, а на деле имеем то, что имеем - такой подарок писателям RTOS-ов под AVR :-)

Писателям RTOSов должно быть грубоко фиолетово как работает стек. Главное что работает.

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

Так что здесь Atmel'овцы молодцы, вопреки уже реализованной аппаратной схеме предекремента для адресных регистров X, Y, Z - со стеком они работают правильно через постдекремент.

[osnwt]

Но это только версия, а на деле имеем то, что имеем - такой подарок писателям RTOS-ов под AVR :-)

Писателям RTOSов должно быть грубоко фиолетово как работает стек. Главное что работает.

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

Нет, я, конечно, согласен, что сделать можно под любую схему. Но см. ниже.

Так что здесь Atmel'овцы молодцы, вопреки уже реализованной аппаратной схеме предекремента для адресных регистров X, Y, Z - со стеком они работают правильно через постдекремент.

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

[defunct]

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

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

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

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

[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. Ваши высказывания, уважаемые собеседники, пока лично меня не убедили в прогрессивности этого шага (что я аргументировал по пунктам). Потому пока остаюсь при своем мнении.