ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
2 июня
146393
fk0, легенда (28.01.2009 16:36, просмотров: 4396)
Дайте мысль нахаляву. Hi-Tech C PICC18. Исчерпался компилированныйк стек. Причина понятна, программа большая, дофига вариантов вроде следующего: функция A вызывает функцию C, функция B тоже вызывает функцию C -- следовательно в момент вызова C стек будет по наибольшему смещению от начала (чтоб и из A и из B работать без накладок). А когда таких функций много (вызываемых часто и откуда попало) стек растёт сильно быстрей. Хоть в нём и полно неиспользуемых "дырок", в графе вызовов (*.map файл) это видно. В итоге рано или поздно сообщение компилятора can't allocate XXX bytes in section param in segment RAM. Как, спрашивается с этим бороться? Я, подчеркну особо, проблема не в автоматических локальных переменных, которые конечно тоже увеличивают использование стека (против чего помогает static и malloc). Суть проблемы, что например для функции нужно пара байт под локальные переменные и аргументы, а offset сильно больше, байт на 50 разом, из-за вызываемости в разных местах. Понятно, что смотреть граф и по возможности как-то исключать часто вызываемые отовсюду функции, возможно, их локальными для модуля копиями. Сокращать глубину графа вызовов, например, путём выделения каких-либо функций в "конечный автомат" с его запуском в основном цикле и т.п. Но это ж натурально ГОВНОКОД получается, кто его поддерживать и отлаживать будет? Всё-таки подумал, static, блин, помогать должен даже где мало на стеке требуется совсем, но аргументы? Для аргументов нельзя задавать storage class и они всё равно будут давать гигантские offset на пустом месте. Функции без аргументов -- опять говнокод. :-( Дайте идею. Как бороться? Глянул на C18 -- ещё хуже. Только из-за const char (который в rom) уже не просто говнокод, а мегаговнокод, т.е. писать специально-под-пик -- всерьёз рассматривать даже нечего. Авторы hitech надо признать постарались и сделали многое для достаточно посредственной архитектуры (GCC и AVR к слову те же проблемы, что и у C18, решены тоже достаточно грязно, у Keil опять же примерно как у hitech сделано, для x51 имею ввиду).
[ZX]