Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
21 июля

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

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

869498 Топик полностью

VLLV (07.09.2018 13:17, просмотров: 188) ответил Ксения на По моему мнению, размеры стека у IAR задаются вручную, и компилятор не имеет права этот размер изменять, в том числе и оптимизировать.

Речь идет про разницу в указателе стека до вызова функции и внутри нее.

Ответить

- Если вылез за пределы стека, то компилер просто обругает, что 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)