caxapa.ru :: Господа программисты, философский вопрос, а заоптимизирует ли компилятор (ИАР) размер стека под динамические переменные внутри функции, если они одновременно не используются? Пропадание динамической переменной в отладчике после ее использования

VLLV (07.09.2018 11:49, просмотров: 13548)

Господа программисты, философский вопрос, а заоптимизирует ли компилятор (ИАР) размер стека под динамические переменные внутри функции, если они одновременно не используются? Пропадание динамической переменной в отладчике после ее использования не с этим связано?

Ответить

- Зачем разводить философию, если можно проверить? Я написал функцию int foo( int a ) { int b = a+1; int c = b*2; int d = c-3; return d*d; } ИАР не выделил места на стеке ни для одной локальной переменной, все вычисления происходят в регистре R0. йцукен(96 знак., 07.09.2018 14:08)
  - Зачем проверять, если можно почитать инструкцию к компилятору? misyachniy(60 знак., 09.09.2018 15:32)
    - один вопрос - при чем тут "передается"? - VLLV(09.09.2018 21:07)
      - Передача параметров в функцию misyachniy(1076 знак., 09.09.2018 21:19, ссылка)
        
        но вопрос то был не про передачу, ну перечитайте же - VLLV(09.09.2018 21:52)
        
        До 4 переменных разместит в R0..R3. misyachniy(1130 знак., 09.09.2018 22:14)
        
        Примочка и в IAR EWAVR есть. Одна галочка в настройках среды и под отладчиком прекрасно видно сколько стека было съедено по максимуму. - AlexG(10.09.2018 05:08)
        
        Мисячный - телепат 80-го уровня. Вычислил проц Владимира одной левой. Возьми с полки пирожок. - SciFi(09.09.2018 21:24)
        
        Та лехко... У какого проца, нонче нет R0...R3? - mse homjak(09.09.2018 21:38)
        
        STM8? - SciFi(09.09.2018 21:39)
        
        Ну... Разве это проц? - mse_mse(10.09.2018 16:07, )
        
        Не надо грязи. - SciFi(10.09.2018 16:28)
        
        Дык, 42года назад, даже у 8048 уже были Р0...Р3! Даже больше. - mse homjak(10.09.2018 21:29)
- По моему мнению, размеры стека у IAR задаются вручную, и компилятор не имеет права этот размер изменять, в том числе и оптимизировать. - Ксения(07.09.2018 12:48)
  - Речь идет про разницу в указателе стека до вызова функции и внутри нее. - VLLV(07.09.2018 13:17)
    - Если вылез за пределы стека, то компилер просто обругает, что CSTACK мал. - Codavr(07.09.2018 13:20)
      - Боюсь, что не обругает. Не знаю как сейчас, но прежде глубину вложения функций друг в друга компилятор/линкер не анализировал. А на форумах очень часто повторялся вопрос, как определить минимальный размер стека, т.к. ОЗУ тогда у МК было очень мало Ксения(23 знак., 07.09.2018 13:46)
        
        Пардон, на CSTACK он ругается когда памяти не хватает. И говорит, что он слишком велик :) - Codavr(07.09.2018 13:50)
        
        Не вижу я в ассемблерном листинге такой on-run проверки. И на момент компиляции этого не проверить, т.к. вложенные друг в друга функции могут находиться в разных модулях, компилируемых отдельно. А линкер тоже не сможет сообразить, т.к. у Ксения(92 знак., 07.09.2018 14:14)
        
        Я прям даже не знаю. Действительно проблема? s_h_e(83 знак., 07.09.2018 18:15, ссылка)
        
        А вот про яр - s_h_e(07.09.2018 18:30, ссылка)
        
        Вот тут еще - LightElf(11.09.2018 18:01, ссылка)
        
        Логично. - Codavr(07.09.2018 14:25)
        
        Лично я в прошлом, когда ATTiny2313 программировала (памяти у нее мало было), заполняла стек кодом 0xFF и после какого-то срока работы проверяла границу, насколько мои 0xFF сохранились. Оказалось, что больше всего стека жрут обработчики Ксения(362 знак., 07.09.2018 14:46)
        
        Вот вот, я тоже всегда офигевал почему он все регистры сохраняет, а не только те что портит. Причем независимо от уровня оптимизации. Помнится один проект в 8 мегу упихал убрав из кода ненужные сохранения/восстановления. Даже пара байтов осталась Codavr(3 знак., 07.09.2018 17:13)
        
        А я сразу догадалась почему :) - если в обработчике прерываний вызовешь хотя бы одну функцию, то компилятор сохраняет все, т.к. не хочет поверять, какие регистры это функция портит. А если не вызывать оттуда функций, то сохраняет только те, что Ксения(32 знак., 07.09.2018 18:10)
        
        Точно. Я так для 15тиньки программы на си писал. В фоне только инициализация и пустой цикл, а все остальное на прерываниях развешано. Правда все равно нужно было править ручками патамушта в тиньке нет пары команд которые компилер с опцией -v0 Codavr(42 знак., 07.09.2018 18:16)
        
        вероятно, чтобы упростить жизнь программерам :) в этом случае не нужно думать, что там будет использовать функция, вызванная явно из хэндлера прерывания :) а вообще конечно это лютый треш "сохранять всё на всякий случай" :)) но зато Adept(385 знак., 07.09.2018 17:21)
        
        Блин, опять я о вызовах не подумал. Ксения только что на пальцах объяснила, что нет никакой возможности определить кто и что сделает в функции из другого модуля. Это ясно только после линковки. Наверное пора менять концепцию, сквозная компиляция Codavr(84 знак., 07.09.2018 17:50 - 17:52)
        
        У компилятора здорового человека это называется "link time optimization" - lloyd(08.09.2018 11:07)
        
        Галочка "Multi-file Compilation" в IARе есть давно. AlexG(76 знак., 07.09.2018 18:04)
        
        "Multi-file Compilation" просто запускает на компиляцию несколько или даже все модули в разных потоках (по потоку на модуль). Не верю, что программа от этого уменьшается в размере. - Ксения(07.09.2018 18:19)
        
        Дудки. Компилятор смотрит сразу на все исходники и может оптимизировать, как будто исходник один. - SciFi(07.09.2018 18:22)
        
        При включении этой галки прога (4 файла) выросла с 0x0E1E до 0x0E2E, правда включена максимальная оптимизация по скорости. Если оптимизируем по размеру, то с 0х0C8E уменишилась до 0х0C6E. Есть эффект! - Codavr(07.09.2018 18:26 - 18:32)
        
        Ага, оптимизируешь скорость, а измеряешь не скорость, а объём кода. А ещё ругаешься, что деток учат печеньки продавать. При этом сам что-то тут впариваешь сомнительными методами :-) - SciFi(07.09.2018 18:32)
        
        Когда этой галки не было я игрался оптимизацией для каждого файла в отдельности, чтобы умять код. На некоторых меньший получается при оптимизации по скорости. Но это у меня приключилось еще на 3 версии. - Codavr(07.09.2018 18:44)
        
        Я уже все проверил и написал, а ты просто воспользовался тем что я тебе объяснил, чтобы меня уесть :) - Codavr(07.09.2018 18:33)
        
        Не подставляйся :-) - SciFi(07.09.2018 18:35)
        
        Да уж, пропустил по запарке :) - Codavr(07.09.2018 18:40)
        
        Проверил. Программа не изменилась ни на байт. - Codavr(07.09.2018 18:22)
        
        Что это доказывает? Может, у тебя программа такая. - SciFi(07.09.2018 18:23)
        
        Это однофайловый вариант. - Codavr(07.09.2018 18:27)
        
        Упс! А я как-то не обращал на нее внимания. Все по старинке. Спасибо за наводку. - Codavr(07.09.2018 18:07)
- Тут есть ньюансы. В общем случае компилятор не знает, когда ячейка памяти выделенная под переменную прекращает использоваться если, например, брался адрес этой ячейки. Тогда она должна сохраняться до конца блока или функции. Если адрес не брался, fk0(480 знак., 07.09.2018 11:57)
  - Варианты гарантированно исключить ненужное разрастание стека банальные - массив байт с приведением типа к нужному или union типизированных переменных, наверно лучше подстраховаться. - VLLV(07.09.2018 12:25)
    - Надеюсь, с этим кодом никому кроме вас не придется разбираться? - s_h_e(07.09.2018 14:53)
      - Коллега разбирается и не с таким говнокодом - VLLV(07.09.2018 16:08)
    - "гарантированно исключить ненужное разрастание стека" - это зачем вообще? Улучшательство ради улучшательства? Обычно задача стоит так: вот есть столько-то ОЗУ, изволь уложиться. К решению этой задачи подходят несколько иначе. - SciFi(07.09.2018 12:31)
      - Может и так, но при написании программы хочется сразу писать фрагменты так, чтобы потом к ним не возвращаться в поисках последнего байта ОЗУ. - VLLV(07.09.2018 13:15)
        
        Моё ИМХО - просто не нужно на пустом месте ресурс разбазаривать, этого достаточно. А лезть из кожи вон заранее - это лишнее. - SciFi(07.09.2018 13:18)
        
        Спасибо! - VLLV(07.09.2018 16:07)
- Оптимизирующий компилятор точно следит за временем (необходимой) жизни переменной и пользуется этим. Другое дело, является ли экономия стека одной из целей оптимизации? Об этом почему-то молчат. Кроме того, освобождение кусочков стека - это, как SciFi(115 знак., 07.09.2018 11:55)

Средства и методы разработки