Добрый день, уважаемые коллеги!
Компилятор размещает локальные переменные, определенные в теле функции либо в регистрах, либо в стеке.

Если переменная 1 или 2-х байтная, то скорее всего компилятор ее разместит в регистрах.
А мне нужно, чтобы он принудительно разместил ее (Var2) в сегменте стека.
А еще лучше, если сразу Var1 будет размещаться в стеке.
Как мне его это заставить сделать?

Вызвать подпрограмму, которой передать в качестве аргумента адрес Var2.


void dummy(int *p)
{
}

void func(void)
{
int Var2;
dummy(&var2);
}

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

В вызываемой подпрограмме - да. А в вызывающей переменная будет создана на стеке, ибо регистры (по крайней мере в данной архитектуре) адреса не имеют.

Это зависит от компилятора. В IAR, например, передача параметров функции производится через регистры R15-R12. Если же размер параметров функции превышает совокупный размер этих регистров то тогда да, параметры передаются через стек.

Для того, чтобы передать адрес переменной, эта переменная должна иметь адрес, т.е. находиться в памяти а не в регистрах. Что и требовалось.

Извиняюсь, невнимательно прочитал сообщения топика.

Похоже я тоже невнимательно читал. Если передавать Var1 прямо в стеке, можно попробовать что-то вроде По идее структура должна передаваться через стек, но никто не гарантирует, что оптимизатор не окажется слишком умным и не решит, что такая структура влезет и в регистр.

Ребят, ну давайте не пытаться быть умнее компилятора! :-)
Я вот прикинул.... Я пишу программы для микропроцессоров и микроконтроллеров 22 года, из них 16 последних на ЯВУ, и ни разу не задумывался, как передаются параметры в функцию.

ссори за долгое отсутствие

Пишу для микропроцессоров менее 22 лет, но вот пришлось задуматься где передаются параметры
Есть девайс (ККМ), в котором пользователь иногда запускает "критический" процесс с "критическими" секциями исполнения программы. Например печать журнала чеков. Если при печати вырубается питание, то по включении ККМ должна продолжить печать с того чека, на котором прервалась печать. Причем все накопления по предыдущим чекам не должны пропасть.
Что я делаю:
1. при выключении питания по прерыванию сохраняю адрес критической секции (печать одного чека)
2. ее параметры - номер чека и прочее
3 и стек в котором лежат локальные переменные

По включению девайс:
1. проходит все начальные тесты и прочее
2. смотрит была ли "свертка"
3. если была, восстанавливаю адрес верхушки стека
и его содержимое
4. перехожу по адресу


Теперь, полагаю, уважаемой публике стало понятно, почему собственно встал вопрос топика.
Локальные переменные, которые в стеке свои значения "сохранили" от старого сеанса,
а которые в регистрах - похерились!
Можно, конечно, при свертке еще и регисты сохранять, но думал, что можно забороть умный копмилятор еще более умной директивой или ключевым словом, которые я не нарыл
Пока решил проблему так:
чтобы меньше переделывать код тупо "умыл" компилятор, объявив Var2 8-ым байтным long long'ом (в регистры запухнуть это копмилятору оказалось слабо)!

Кстати, если мне не изменяет память, я уже как то поднимал эту тему на форуме, было бы интересно узнать, кто как сворачивается-разворачивается по выкл/вкл в аналогичных ситуациях.

ИМХО проще иметь глобальную структуру глобальных переменных. Тогда критические данные можно разместить последовательно (рядом) в такой структуре. Сохранять их в таком случае проще - всегда известно где они лежат и каков размер критической секции данных.
"Рубанули питание" для случая применения MSP430 звучит несколько странно. Если есть детектор "вырубания", то конденсатора на две-три сотни мкФ или ионистора (или литиевой батарейки на худой конец) вполне хватит чтобы завершить сохранение критически важных данных.

Скажите, а как Вы успеваете сохранится? Ведь у вас термопринтер потребляет немало...
Вы уверены, что Z или X отчет надо продолжать печатать с того же места, а не заново?

А для того чтобы данные передавались как вам надо, может проще эти процедуры на ассемблере написать?

Ну, теперь понятно

1. Использую измерение напряжения до стабилизатора, чтобы вовремя отключить все энергопотребляющие узлы, чтобы контроллер насладился сохранением статистики в ЕЕПРОМ.
2. Чтобы статистика не попортилась, делаю это только только в критических местах.
3. Реализую алгоритм прибора в виде массива функций, а текущим индексом массива является глобальная переменная "статус".
4. Не использую стек для таких функций, но, чтобы памяти хватило, использую одни и те же глобальные переменные в каждой функции, переопределяя их каждый раз в целях соответствия имени физическому смыслу (комментарии не пишу, компенсируя это именами).

Собственно, все... После сброса контроллер инициализируется и сразу выходит на ту функцию, где он был.

Были мысли про стек, но больше риск влететь куда-то не туда, и возникает зависимость от платформы, а я это не люблю - контроллеры приходят и уходят, а люди остаются

Да, еще... (прочитал, что написал ув. Rezident) - пп 3 и 4 нужны , если нужно быстро перезапуститься (например, помехи жуткие и проч.) Если обычный процесс выключения, пусть нештатного - можно ведь сохраниться в EEPROM без проблем - т.е. пп. 1 и 2 достаточно.

Попробуйте объявить ее как auto. А вообще, компилятор достаточно "умный". Он должен "увидеть" ссылку на адрес переменной и разместить ее в стеке.

Как говориться, кто в лес, а кто по дрова!
Хм, разве была речь о том, что чего там не хватит для сохранения чего то???
Агрументы самой свертки разумеется универсальны и лежат в глобальной структуре.
Но вот после того как куда-то вернулись и продолжаем рабуту дальше в "штатном режиме" по функционалу, тут уже в разных функциях по разному и универсальными глобальными структурами не опишешь. Не универсальный механизм получается, бестолково.


Абсолютно верно, но это только мы знаем, что проц полюбому на батарейке и что тумблером аппаратно вырубается только принтер и подсветка индикатора, а проц ушел в LPM3


Термопринтер, индикатор разумеется вырубается сразу по тумблеру.
Коллега, не путайте: X/Z-отчет - это одно, а КЛ (контрольная лента) - это другое.
Отчеты по свертке перепечатываются заново, а печать КЛ продолжается с того чека, где зарубились (чек перепечетывается заново). Но это уже заморочки ТУ на девайс

Эк, Вы куда, коллега, хватили!

Извините, но ничего нового не узнал. Это все общеизвестная теория.
Кстати, если тоже немного потеоритизировать и рассмотреть случай когда контроллер не сидит на отдельной элементе питания, то записывая свертку в ЕЕПРОМ не пару байт, а поболе можно нарваться на недозапись; через год-два на уже несвежих кондерах. Свертку желательно сохранять в более быструю память. Проверено жизнью.

Меня интересует конкретика: девайс на MSP430F449; сворачиваться требуется в не одном, а в 10-ке мест (функциях); внутренний структура обрабатываемых данных во всех функциях совершенно различна.

А откуда возмется "все то, что было нажито непосильным трудом" в каждой конткретной функции до выключения питания??? В каждом случае сохраняетесь "вручную" (пишите отдельный код в прерывании под каждый случай)?

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

P.S. Коллеги, благодарю всех за отклики и ответы.


Проверено. Не помогает.

Ну, для меня это не теория, а практика любого проекта.

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

Я же писал - то, что нужно после сброса для продолжения работы - в глобальных переменных. Если данные нужны и для сохранения после долгого выключения - то в буфере для сохранения в EEPROM.