Як видавити код, щоб отримати більше Flash та RAM? [зачинено]

Я працював над розробкою функції для певного нашого продукту. Був запит на перевезення тієї ж функції до іншого продукту. Цей продукт базується на мікроконтролері M16C, який традиційно має 64K Flash та 2k оперативної пам’яті.

Це зрілий продукт, а отже, лише 132 байти Flash та 2 байти оперативної пам’яті.

Щоб перенести запитувану функцію (сама функція оптимізована), мені потрібно 1400 байт Flash та ~ 200 байт оперативної пам’яті.

Хтось має пропозиції щодо отримання цих байтів шляхом ущільнення коду? На які конкретні речі я звертаю увагу, коли намагаюся ущільнити вже існуючий робочий код?

Будь-які ідеї дійсно будуть оцінені.

Спасибі.

У вас є пара варіантів: спочатку потрібно шукати зайвий код і перемістити його в один виклик, щоб позбутися від дублювання; друге - зняти функціональність.

Погляньте на свій файл .map і перевірте, чи є функції, які ви можете позбутися або переписати. Також переконайтесь, що дзвінки до бібліотеки, які використовуються, дійсно потрібні.

Деякі речі, такі як поділ та множення, можуть вносити багато коду, але використання зрушень та кращого використання констант може зменшити код. Також подивіться на такі речі, як рядкові константи та printfs. Наприклад, кожен printfз’їсть ваш ром, але, можливо, ви зможете мати пару рядків спільного формату, а не повторювати цю константну константу знову і знову.

Для пам’яті подивіться, чи можете ви позбутися глобалістів і замість цього використовувати авто в функції. Також уникайте якомога більшої кількості змінних в основній функції, оскільки вони з'їдають пам'ять так само, як і глобальні.

Завжди варто переглядати вихідний файл (асемблер), щоб шукати речі, на які особливо ваши компілятори.

Наприклад, ви можете виявити, що локальні змінні дуже дорогі, і якщо додаток досить простий, щоб бути вартим ризику, переміщення декількох лічильників циклу в статичні змінні може заощадити багато коду.

Або індексація масиву може бути дуже дорогою, але операції з покажчиками значно дешевші. Або навпаки.

Але перегляд мови складання - це перший крок.

Оптимізація компілятора, наприклад, -Osу GCC дає найкращий баланс між швидкістю та розміром коду. Уникайте -O3, оскільки це може збільшити розмір коду.

Для оперативної пам’яті перевірте діапазон усіх змінних - ви використовуєте вставки, де ви могли б використовувати знак? Чи буфери більше, ніж потрібно?

Видавлювання коду дуже залежить від застосування та кодування. Залишені вами суми говорять про те, що, можливо, код уже пішов, хоча певне стискання, що може означати, що залишилося мало.

Також уважно погляньте на загальну функціональність - чи є щось, що насправді не використовується і яке може бути вимкнено?

Якщо це старий проект, але компілятор був розроблений з тих пір, можливо, більш пізній компілятор може створити менший код

Завжди варто перевірити у посібнику з компілятора параметри для оптимізації простору.

Для МКІ -ffunction-sectionsі -fdata-sectionsз --gc-sectionsпрапором компоновщика гарні для зняття мертвого коду.

Ось кілька чудових порад (орієнтованих на AVR)

Ви можете вивчити кількість виділеного простору та кучу простору. Можливо, ви зможете отримати значну кількість оперативної пам’яті, якщо один або обидва з них перерозподілені.

Я думаю, для проекту , який влазить в 2к ОЗУ для початку немає динамічного розподілу пам'яті (використання malloc, callocі т.д.). Якщо це так, ви можете позбутися від вашої купи взагалі, припускаючи, що оригінальний автор залишив трохи оперативної пам’яті, виділеної для купи.

Ви повинні бути дуже обережними, зменшуючи розмір стека, оскільки це може спричинити помилки, які дуже важко знайти. Може бути корисним для початку, ініціалізуючи весь простір стека до відомого значення (щось інше, ніж 0x00 або 0xff, оскільки ці значення зазвичай трапляються), потім запустити систему деякий час, щоб побачити, скільки місця в стеці не використовується.

Чи використовує ваш код математику з плаваючою комою? Можливо, ви зможете повторно реалізувати свої алгоритми, використовуючи лише цілу математику, і усунути накладні витрати на використання бібліотеки з плаваючою точкою C. Наприклад, у деяких програмах такі функції, як sine, log, exp можуть бути замінені цілими поліноміальними наближеннями.

Чи використовує ваш код великі таблиці пошуку для будь-яких алгоритмів, таких як обчислення CRC? Ви можете спробувати замінити іншу версію алгоритму, яка обчислює значення на ходу, замість того, щоб використовувати таблиці перегляду. Застереження полягає в тому, що менший алгоритм, швидше за все, повільніше, тому переконайтеся, що у вас достатньо циклів процесора.

Чи є у вашому коді велика кількість постійних даних, таких як рядкові таблиці, HTML-сторінки або піксельна графіка (піктограми)? Якщо вона достатньо велика (скажімо, 10 кБ), можливо, варто застосувати дуже просту схему стиснення, щоб зменшити дані та декомпресувати її в ході, коли це потрібно.

Можна спробувати перевпорядкувати, щоб кодувати багато, на більш компактний стиль. Багато що залежить від того, що робить код. Ключ полягає в тому, щоб знайти подібні речі та повторно реалізувати їх з точки зору один одного. Крайнім буде використання мови вищого рівня, як, наприклад, Forth, за допомогою якої можна легше досягти більш високої щільності коду, ніж у C або асемблері.

Ось Forth для M16C .

Встановіть рівень оптимізації компілятора. Багато IDE мають налаштування, які дозволяють проводити оптимізацію розміру коду за рахунок часу компіляції (або, можливо, навіть час обробки в деяких випадках). Вони можуть виконати ущільнення коду, повторно перезапустивши свого оптимізатора, шукаючи менш поширені шаблони для оптимізації та цілу низку хитрощів, які можуть не знадобитися для випадкової компіляції / налагодження. Зазвичай за замовчуванням компілятори встановлюються на середній рівень оптимізації. Переконайтесь у налаштуваннях, щоб ви мали змогу знайти якусь шкалу оптимізації на основі цілих чисел.

Якщо ви вже використовуєте компілятор професійного рівня, як IAR, я думаю, що ви будете намагатися отримати будь-які серйозні заощадження за допомогою незначного налаштування коду низького рівня - вам потрібно буде більше шукати питання щодо видалення функціональності або виконання основних переписує деталі більш ефективно. Вам знадобиться бути розумнішим кодером, ніж той, хто написав оригінальну версію ... Що стосується оперативної пам'яті, вам потрібно дуже уважно поставитися до того, як вона використовується в даний час, і побачити, чи є можливість для накладення використання тієї ж ОЗУ для різні речі в різний час (профспілки зручні для цього). Розміри купівлі та стека IAR за замовчуванням у ARM / AVR, які я, як правило, надмірно щедрі, тому це було б першим, що слід подивитися.

Щось ще потрібно перевірити - деякі компілятори в деяких архітектурах копіюють константи в оперативну пам’ять - зазвичай використовуються, коли доступ до констант флеш повільний / складний (наприклад, AVR), наприклад, компілятор AVR IAR вимагає _ _flash кваліфікатора, щоб не копіювати константу в оперативну пам'ять)

Якщо ваш процесор не має апаратної підтримки для параметра / локального стека, але компілятор намагається все-таки реалізувати стек параметрів виконання, і якщо ваш код не потребує повторного введення, ви можете зберегти код простір шляхом статичного розподілу автоматичних змінних. У деяких випадках це потрібно робити вручну; в інших випадках директиви компілятора можуть це зробити. Для ефективного ручного розподілу буде потрібно обмін змінними між процедурами. Такий обмін повинен здійснюватися обережно, щоб переконатися, що жодна програма не використовує змінну, яку інша рутина вважає "за обсягом", але в деяких випадках переваги розміру коду можуть бути значними.

Деякі процесори мають умовні виклики, які можуть зробити деякі стилі передачі параметрів більш ефективними, ніж інші. Наприклад, на контролерах PIC18, якщо підпрограма приймає один однобайтовий параметр, вона може передаватися в регістр; якщо це займає більше, всі параметри повинні бути передані в оперативній пам'яті. Якщо звичайна програма прийме два однобайтові параметри, можливо, найефективніше "передавати" один у глобальній змінній, а потім передавати інший як параметр. При широко використовуваних процедурах заощадження можуть збільшити. Вони можуть бути особливо значущими, якщо параметр, переданий через глобальний, є однобітним прапором або якщо він, як правило, має значення 0 або 255 (оскільки існують спеціальні інструкції для зберігання 0 або 255 в ОЗУ).

У ARM введення глобальних змінних, які часто використовуються разом у структурі, може значно зменшити розмір коду та підвищити продуктивність. Якщо A, B, C, D і E є окремими глобальними змінними, то код, який використовує всі, повинен завантажувати адресу кожного в реєстр; якщо регістрів недостатньо, можливо, доведеться перезавантажувати ці адреси кілька разів. На противагу цьому, якщо вони є частиною тієї самої глобальної структури MyStuff, то код, який використовує MyStuff.A, MyStuff.B, тощо, може просто завантажити адресу MyStuff один раз. Великий виграш.

1. Якщо ваш код покладається на безліч структур, переконайтеся, що члени структури впорядковані з тих, які займають найбільше пам'яті.

Наприклад: "uint32_t uint16_t uint8_t" замість "uint16_t uint8_t uint32_t"

Це забезпечить мінімальну обшивку структури.

2. Використовуйте const для змінних, де це можливо. Це забезпечить, що ці змінні будуть знаходитися в ПЗУ, а не з'їдати оперативну пам'ять

Кілька (можливо очевидних) хитрощів, які я успішно використовував для стискання коду клієнта:

1. Компактні прапори в бітові поля або бітові маски. Це може бути вигідним, оскільки зазвичай булеві файли зберігаються як цілі числа, таким чином витрачаючи пам'ять. Це дозволить заощадити і оперативну пам'ять, і ROM, і зазвичай це не робиться компілятором.

2. Шукайте надмірність у коді та використовуйте петлі або функції для виконання повторних операторів.

3. Я також врятував деякий ПЗУ, замінивши багато if(x==enum_entry) <assignment>висловлювань констант індексованим масивом, подбавши про те, щоб записи перерахунків могли використовуватися як індекс масиву

Якщо ви можете, використовуйте вбудовані функції або макроси компілятора замість малих функцій. Є розмір і швидкість накладних витрат з передачею аргументів, і такі, які можна усунути, зробивши функцію вбудованою.

Змініть локальні змінні, щоб вони були однакового розміру ваших регістрів процесора.

Якщо процесор 32-розрядний, використовуйте 32-бітні змінні, навіть якщо значення max ніколи не перевищить 255. Я використовував 8-бітну змінну, компілятор додасть код для маскування верхніх 24 біт.

Перше місце, на яке я звернувся б, - це змінні for-loop.

for( i = 0; i < 100; i++ )

Це може здатися хорошим місцем для 8-бітної змінної, але 32-бітова змінна може створювати менше коду.