Решил погонять математику с большими числами на м128 (макс. число 1000000 исп типы: unsigned long int, unsigned int, unsigned char) поперемножать их повычитать,в общем все с ними поделать.Результаты выкидываю на ЖКИ.Компилил в КодеВижне,
так вот компилятор говорит что стека ему надо 312 байт я ему и поставил 320 и проц пару раз число умножит,поделит и виснет если же ему стека 2048 байт впендюрить то проц очень даже долго работает
целых 23 операции без бэ выполняет а потом гонит и виснет.
Не подскажите в чем тут дело......такое чувство что RAMа засирается постепенно.

рекурсией не баловались?

Если это заключается в вызове данной функции из самой этой функции то да баловался

Рекурсия, скорее всего, тут ни при чём, так как иначе не выполнилось бы ни одного умножения и всё погрязло бы в бесконечном цикле. Возможно, где-то внутри функции создаётся память оператором new , а по выходе из неё не удаляется delete. Возможно, что эта бага зарыта в библиотеке, если вы таковой пользуетесь. Возможно, в библиотечной функции не соответствует количество PUSH при входе в функцию количеству POP при выходе из неё.
Если есть вставки на Ассемблере, то наивероятнейшая причина - та же - несоответствие количества операторов PUSH количеству операторов POP.

Я не юзал либы а только обычные операции: "/", "*", "-", "+"

и асмовые вставки не делал

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

попробуйте поставить галочку stack end marker, возможно в этом дело

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

Проверьте, не выполняется ли где-нибудь в программе деление на ноль. Я однажды так очень долго мучился с поиском ошибки... Правда в моем случае МК просто перезагружался... но это в моем случае)

А что в этом случае должно получиться? Деление это ведь вычитание. Арифметикой пользуюсь, но проверяю чтобы небыло /0.
Извените, что на пол шага от вопроса отошел.

Если конкретно, то компилятор пишет обычно следующее:
"
Data Stack area: 60h to DFh
Data Stack size: 128 byte(s)
Estimated Data Stack usage: 22 byte(s)
"
т.е. он показывает приблизительный на его взгляд размер стека. Но в случае длинной рекурсии компилятор может очень сильно ошибаться. Может быть дело в этом.

Всем спасибо ! решилось.Я юзал рекурсию из-за чего стек уходил в область программы.

дак вы в симуляторе VMLAB посмотрите что происходит в меге.