Codavr (07.09.2018 13:20, просмотров: 237) ответил VLLV на Речь идет про разницу в указателе стека до вызова функции и внутри нее.Долой империалистический интернационал!
-
- Боюсь, что не обругает. Не знаю как сейчас, но прежде глубину вложения функций друг в друга компилятор/линкер не анализировал. А на форумах очень часто повторялся вопрос, как определить минимальный размер стека, т.к. ОЗУ тогда у МК было очень мало Ксения(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, ссылка)
- А вот про яр - s_h_e(07.09.2018 18:30, ссылка)
- Логично. - 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)
- вероятно, чтобы упростить жизнь программерам :) в этом случае не нужно думать, что там будет использовать функция, вызванная явно из хэндлера прерывания :) а вообще конечно это лютый треш "сохранять всё на всякий случай" :)) но зато 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)
- Не подставляйся :-) - SciFi(07.09.2018 18:35)
- Ага, оптимизируешь скорость, а измеряешь не скорость, а объём кода. А ещё ругаешься, что деток учат печеньки продавать. При этом сам что-то тут впариваешь сомнительными методами :-) - SciFi(07.09.2018 18:32)
- При включении этой галки прога (4 файла) выросла с 0x0E1E до 0x0E2E, правда включена максимальная оптимизация по скорости. Если оптимизируем по размеру, то с 0х0C8E уменишилась до 0х0C6E. Есть эффект! - Codavr(07.09.2018 18:26 - 18:32)
- Проверил. Программа не изменилась ни на байт. - Codavr(07.09.2018 18:22)
- Что это доказывает? Может, у тебя программа такая. - SciFi(07.09.2018 18:23)
- Это однофайловый вариант. - Codavr(07.09.2018 18:27)
- Что это доказывает? Может, у тебя программа такая. - SciFi(07.09.2018 18:23)
- Дудки. Компилятор смотрит сразу на все исходники и может оптимизировать, как будто исходник один. - SciFi(07.09.2018 18:22)
- Упс! А я как-то не обращал на нее внимания. Все по старинке. Спасибо за наводку. - Codavr(07.09.2018 18:07)
- "Multi-file Compilation" просто запускает на компиляцию несколько или даже все модули в разных потоках (по потоку на модуль). Не верю, что программа от этого уменьшается в размере. - Ксения(07.09.2018 18:19)
- Блин, опять я о вызовах не подумал. Ксения только что на пальцах объяснила, что нет никакой возможности определить кто и что сделает в функции из другого модуля. Это ясно только после линковки. Наверное пора менять концепцию, сквозная компиляция Codavr(84 знак., 07.09.2018 17:50 - 17:52)
- Вот вот, я тоже всегда офигевал почему он все регистры сохраняет, а не только те что портит. Причем независимо от уровня оптимизации. Помнится один проект в 8 мегу упихал убрав из кода ненужные сохранения/восстановления. Даже пара байтов осталась Codavr(3 знак., 07.09.2018 17:13)
- Лично я в прошлом, когда ATTiny2313 программировала (памяти у нее мало было), заполняла стек кодом 0xFF и после какого-то срока работы проверяла границу, насколько мои 0xFF сохранились. Оказалось, что больше всего стека жрут обработчики Ксения(362 знак., 07.09.2018 14:46)
- Я прям даже не знаю. Действительно проблема? s_h_e(83 знак., 07.09.2018 18:15, ссылка)
- Не вижу я в ассемблерном листинге такой on-run проверки. И на момент компиляции этого не проверить, т.к. вложенные друг в друга функции могут находиться в разных модулях, компилируемых отдельно. А линкер тоже не сможет сообразить, т.к. у Ксения(92 знак., 07.09.2018 14:14)
- Пардон, на CSTACK он ругается когда памяти не хватает. И говорит, что он слишком велик :) - Codavr(07.09.2018 13:50)
- Боюсь, что не обругает. Не знаю как сейчас, но прежде глубину вложения функций друг в друга компилятор/линкер не анализировал. А на форумах очень часто повторялся вопрос, как определить минимальный размер стека, т.к. ОЗУ тогда у МК было очень мало Ксения(23 знак., 07.09.2018 13:46)