jcxz 184 28 января, 2020 Опубликовано 28 января, 2020 · Жалоба 1 час назад, Forger сказал: Вы не понимаете - внутри вызываемой через делегат функции, могу быть другие вызовы. На этапе компиляции компилятор не может правильно выстроить дерево вызовов через такие указатели. Это можно сделать только в runtime. И какая разница что там другие вызовы? У вас и в release и в debug - есть вызовы. И вы думаете что в случае release у вас будут вызываться одни функции, а в случае debug - другие? И что будет чёткая зависимость - в случае debug всегда будут вызываться функции с бОльшим стеком? Только в этом случае суммарное использование стека получится больше. Или всё-таки вызов любой функции (из тех что могут вызываться косвенно) равновероятен что в debug что в release? Цитата Статическое дерево вызовов тут просто бесполезно. Причём тут "статическое дерево вызовов"? Вы это сами придумали, приписали это мне, и теперь пытаетесь со мной спорить. Я не говорил ни о каком "статическом дереве". 1 час назад, Forger сказал: Я понимаю, что бодаться будете до последнего Замечено неоднократно )) Бодаетесь пока что Вы сами с собой. С приписанными мне утверждениями. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 28 января, 2020 Опубликовано 28 января, 2020 · Жалоба 38 minutes ago, jcxz said: И какая разница что там другие вызовы? У вас и в release и в debug - есть вызовы. И вы думаете что в случае release у вас будут вызываться одни функции, а в случае debug - другие? Да, в в среднем вызовы одинаковые, код неизменный. Quote И что будет чёткая зависимость - в случае debug всегда будут вызываться функции с бОльшим стеком? Только в этом случае суммарное использование стека получится больше. Или всё-таки вызов любой функции (из тех что могут вызываться косвенно) равновероятен что в debug что в release? Самое вероятное, почему размер стека жрется в debug, это полное отсутствие оптимизации вызовов некоторых простых функций и применяемых локальных переменных, которые при оптимизации могут заменяться просто регистрами ядра. Quote Причём тут "статическое дерево вызовов"? Имеется ввиду дерево вызовов, которое формирует компилятор на этапе компиляции. Все же правильнее будет назвать compile-time дерево. Но в моих проектах оно бесполезно. Поэтому проанализировать стек с его помощью не получится. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 28 января, 2020 Опубликовано 28 января, 2020 · Жалоба 3 часа назад, HardEgor сказал: Rebuld делали? Просто убрать все галки на дополнительные файлы, перебилдидь, поставить все галки, перебилдить. Удалить .uvguix. файлы. Попробовать ручками удалить папку с всеми промежуточными и дополнительными файлами, а потом сделать build. Ребилдол пил, не помогает. Галки убирал/ставил, удалял папки с выходным шлаком, убирал/ставил галки снова - ноль реакции. .uvguix завтра попробую удалить и посмотрю, что поменяется. А то совсем как-то с такой средой не разгонишься Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 28 января, 2020 Опубликовано 28 января, 2020 · Жалоба 5 minutes ago, Arlleex said: А то совсем как-то с такой средой не разгонишься Да, KEIL - морально устарел, тут что есть, то есть (( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 28 января, 2020 Опубликовано 28 января, 2020 · Жалоба 1 час назад, Forger сказал: Самое вероятное, почему размер стека жрется в debug, это полное отсутствие оптимизации вызовов некоторых простых функций и применяемых локальных переменных, которые при оптимизации могут заменяться просто регистрами ядра. А не пробовали сравнить -o1 и -o3? При -o1 уже есть минимальная оптимизация. 1 час назад, Forger сказал: Имеется ввиду дерево вызовов, которое формирует компилятор на этапе компиляции. Все же правильнее будет назвать compile-time дерево. В том фрагменте .lst что я приводил, в разделе "stack usage" указаны размеры стека занимаемого только самой функцией, а не всем деревом её вызова. Всё дерево я не знаю - умеет ли IAR считать. Поэтому там легко сравнить функции в разных вариантах компиляции. 23 минуты назад, Arlleex сказал: А то совсем как-то с такой средой не разгонишься IAR вам поставить нельзя? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 28 января, 2020 Опубликовано 28 января, 2020 · Жалоба 2 minutes ago, jcxz said: А не пробовали сравнить -o1 и -o3? При -o1 уже есть минимальная оптимизация. Пробовал, но нужные данные уже не отображаются средой (( Видать оптимизатор на -o3 напрочь удаляет все структуры, которые использует среда для анализа этих данных. 2 minutes ago, jcxz said: В том фрагменте .lst что я приводил, в разделе "stack usage" указаны размеры стека занимаемого только самой функцией, а не всем деревом её вызова. В Keil этого нет, по крайней мере мне не удалось получить аналогичные данные (( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 29 января, 2020 Опубликовано 29 января, 2020 · Жалоба 8 часов назад, jcxz сказал: IAR вам поставить нельзя? Можно. Просто я уже так сильно привык к Keil, что вот просто без борьбы сдаться и отказаться от нее не смогу P.S. .uvguix снес, папки лишние снес, открыл проект, убрал галки "Debug Information", "Create HEX File" и "Browse Information". Ребилдол. Снова установил галки обратно, ребилдол. Go to definition на любой определенный символ - та же самая красная хреновина внизу моргает... Не может ли это быть из-за того, что Keil у меня крякнутый? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HardEgor 63 29 января, 2020 Опубликовано 29 января, 2020 · Жалоба 23 минуты назад, Arlleex сказал: P.S. .uvguix снес, папки лишние снес, открыл проект, убрал галки "Debug Information", "Create HEX File" и "Browse Information". Ребилдол. Снова установил галки обратно, ребилдол. Go to definition на любой определенный символ - та же самая красная хреновина внизу моргает... 1. попробовать откатить версию компилятора или накатить новую (я сейчас текущий проект попробовал собрать на v5.06 update 1 build 61 - проблем нету, все definition показывает) 2. если есть контроль версий, то посмотреть что изменилось в свойствах проекта 3. собрать проект заново(мне так два раза приходилось делать). 4. какие-то сторонние проблемы - кончилось место на диске, в путях есть русские буквы или пробелы и т.д. Вспомнил что тема уже всплывала: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Edit2007 3 29 января, 2020 Опубликовано 29 января, 2020 · Жалоба 10 часов назад, Forger сказал: Цитата В том фрагменте .lst что я приводил, в разделе "stack usage" указаны размеры стека занимаемого только самой функцией, а не всем деревом её вызова. В Keil этого нет, по крайней мере мне не удалось получить аналогичные данные (( Вместе с hex-файлом создается html-файл проекта, в котором указан максимальный размер стека (без учета косвенных вызовов и прерываний) и размер стека для каждой функции (в том числе и дерево вызовов) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 29 января, 2020 Опубликовано 29 января, 2020 · Жалоба 1 час назад, HardEgor сказал: 1. попробовать... 2. ... ... Спасибо. Я попробую что-нибудь пошурудить. Может даже среду нафиг снесу и переставлю. P.S. Тот тред помню, это на домашнем компе все ок. А на работе какое-то шаманство Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 29 января, 2020 Опубликовано 29 января, 2020 · Жалоба 50 minutes ago, Edit2007 said: Вместе с hex-файлом создается html-файл проекта, в котором указан максимальный размер стека (без учета косвенных вызовов и прерываний) и размер стека для каждой функции (в том числе и дерево вызовов) На html не обратил внимания, спасибо ! Короче, вот свел в таблицу ниже. Отдельно по задачам нет данных, но в общем кое-что есть (см. OS::AbstractThread) Очевидно, что без оптимизации даже inline функции все равно формируются как полноценный вызов. Стек в итоге пожирается без всяких ограничений. Самая оптимальная получается по ходу balanced, что в целом логично. Поэтому в debug лучше ставить максимум -o1 (для некоторых -o0), а в release - balanced. Что собственно до этого я и делал ) ps компилятор v6.13.1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
