Come spremere il codice per più Flash e RAM? [chiuso]

Ho lavorato allo sviluppo di una funzione su un nostro prodotto particolare. C'è stata una richiesta per il porting della stessa funzione su un altro prodotto. Questo prodotto si basa su un microcontrollore M16C, che tradizionalmente ha 64 KB di Flash e 2 KB di RAM.

È un prodotto maturo e, pertanto, sono rimasti solo 132 byte di Flash e 2 byte di RAM.

Per eseguire il porting della funzione richiesta (la funzione stessa è stata ottimizzata), ho bisogno di 1400 byte di Flash e ~ 200 byte di RAM.

Qualcuno ha qualche suggerimento su come recuperare questi byte dalla compattazione del codice? Quali cose specifiche cerco quando cerco di compattare il codice di lavoro già esistente?

Qualsiasi idea sarà davvero apprezzata.

Grazie.

Hai un paio di opzioni: in primo luogo è cercare il codice ridondante e spostarlo in una singola chiamata per eliminare la duplicazione; il secondo è rimuovere la funzionalità.

Dai un'occhiata al tuo file .map e vedi se ci sono funzioni che puoi eliminare o riscrivere. Assicurati anche che le chiamate in libreria utilizzate siano davvero necessarie.

Alcune cose come la divisione e le moltiplicazioni possono portare un sacco di codice, ma l'uso di turni e un migliore utilizzo delle costanti può ridurre il codice. Dai anche un'occhiata a cose come costanti di stringa e printfs. Ad esempio ognuno printfdivorerà la tua rom ma potresti essere in grado di avere un paio di stringhe di formato condivise invece di ripetere più volte quella costante di stringa.

Per la memoria, vedi se riesci a sbarazzarti dei globi e usa invece le auto in una funzione. Evita anche quante più variabili possibili nella funzione principale, in quanto consumano memoria proprio come fanno i globuli.

Vale sempre la pena guardare l'output del file di elenco (assemblatore) per cercare cose che il tuo particolare compilatore non è particolarmente adatto.

Ad esempio, potresti scoprire che le variabili locali sono molto costose e se l'applicazione è abbastanza semplice da valere il rischio, spostare alcuni contatori di loop in variabili statiche potrebbe risparmiare molto codice.

O l'indicizzazione dell'array potrebbe essere molto costosa, ma le operazioni con i puntatori sono molto più economiche. O vice versa.

Ma guardare il linguaggio assembly è il primo passo.

Le ottimizzazioni del compilatore, ad esempio, -Osin GCC offrono il miglior equilibrio tra velocità e dimensioni del codice. Evita -O3, poiché potrebbe aumentare la dimensione del codice.

Per la RAM, controlla l'intervallo di tutte le tue variabili: stai usando ints dove potresti usare un carattere? I buffer sono più grandi di quanto devono essere?

La compressione del codice dipende molto dall'applicazione e dallo stile di programmazione. I tuoi importi lasciati suggeriscono che forse il codice è già andato via anche se un po 'di compressione, il che potrebbe significare che c'è ancora poco da avere.

Dai anche una occhiata alla funzionalità generale: c'è qualcosa che non è realmente utilizzato e può essere rimosso?

Se si tratta di un vecchio progetto ma il compilatore è stato sviluppato da allora, è possibile che un compilatore più recente possa produrre codice più piccolo

Vale sempre la pena controllare il manuale del compilatore per le opzioni per ottimizzare lo spazio.

Per gcc -ffunction-sectionse -fdata-sectionscon il--gc-sections flag linker sono buoni per rimuovere il codice morto.

Ecco alcuni altri suggerimenti eccellenti (orientati verso AVR)

È possibile esaminare la quantità di spazio stack e spazio heap allocati. Potresti essere in grado di recuperare una notevole quantità di RAM se uno o entrambi di questi sono sovrallocati.

La mia ipotesi è per un progetto che si inserisce in 2k di RAM per cominciare non c'è allocazione dinamica della memoria (uso di malloc, calloce così via). In questo caso è possibile eliminare del tutto l'heap supponendo che l'autore originale abbia lasciato un po 'di RAM allocata per l'heap.

Devi stare molto attento a ridurre le dimensioni dello stack in quanto ciò può causare bug che sono molto difficili da trovare. Potrebbe essere utile iniziare inizializzando l'intero spazio dello stack su un valore noto (qualcosa di diverso da 0x00 o 0xff poiché questi valori si verificano già comunemente), quindi eseguire il sistema per un po 'per vedere quanto spazio dello stack è inutilizzato.

Il tuo codice usa la matematica in virgola mobile? Potresti essere in grado di implementare nuovamente i tuoi algoritmi utilizzando solo la matematica dei numeri interi ed eliminare i costi generali dell'utilizzo della libreria in virgola mobile C. Ad esempio in alcune applicazioni, funzioni come seno, log, exp possono essere sostituite da approssimazioni polinomiali intere.

Il tuo codice utilizza tabelle di ricerca di grandi dimensioni per eventuali algoritmi, come i calcoli CRC? Puoi provare a sostituire una versione diversa dell'algoritmo che calcola i valori al volo, invece di utilizzare le tabelle di ricerca. L'avvertenza è che l'algoritmo più piccolo è molto probabilmente più lento, quindi assicurati di avere abbastanza cicli della CPU.

Il tuo codice contiene grandi quantità di dati costanti, come tabelle di stringhe, pagine HTML o grafica pixel (icone)? Se è abbastanza grande (diciamo 10 kB), potrebbe valere la pena implementare uno schema di compressione molto semplice per ridurre i dati e decomprimerli al volo quando necessario.

Puoi provare a riorganizzare il codice molto, in uno stile più compatto. Dipende molto da cosa sta facendo il codice. La chiave è trovare cose simili e implementarle nuovamente l'una nell'altra. Un estremo sarebbe usare un linguaggio di livello superiore, come Forth, con il quale può essere più facile ottenere una densità di codice maggiore rispetto a C o assembler.

Ecco Forth per M16C .

Imposta il livello di ottimizzazione del compilatore. Molti IDE hanno impostazioni che consentono di ottimizzare le dimensioni del codice a spese del tempo di compilazione (o forse anche del tempo di elaborazione in alcuni casi). Possono eseguire la compattazione del codice rieseguendo il proprio ottimizzatore un paio di volte, cercando modelli meno comuni e ottimizzabili e tutta un'altra serie di trucchi che potrebbero non essere necessari per la compilazione casuale / di debug. Di solito, per impostazione predefinita, i compilatori sono impostati su un livello medio di ottimizzazione. Cerca nelle impostazioni e dovresti essere in grado di trovare una scala di ottimizzazione basata su numeri interi.

Se stai già utilizzando un compilatore di livello professionale come IAR, penso che avrai difficoltà a ottenere seri risparmi da una modifica del codice di basso livello - dovrai guardare di più verso la rimozione di funzionalità o fare importanti riscrive le parti in modo più efficiente. Dovrai essere un programmatore più intelligente di chiunque abbia scritto la versione originale ... Per quanto riguarda la RAM, devi dare uno sguardo molto duro al modo in cui viene attualmente utilizzato e vedere se c'è spazio per sovrapporre l'utilizzo della stessa RAM per cose diverse in momenti diversi (i sindacati sono utili per questo). Le dimensioni di heap e stack predefinite di IAR in quelle ARM / AVR che ho avuto la tendenza ad essere eccessivamente generose, quindi queste sarebbero le prime cose da guardare.

Qualcos'altro da controllare - alcuni compilatori su alcune architetture copiano le costanti nella RAM - in genere utilizzato quando l'accesso alle costanti flash è lento / difficile (ad es. AVR) ad es. Il compilatore IAR AVR richiede una qualifica _ _flash per non copiare una costante in RAM)

Se il tuo processore non ha il supporto hardware per uno stack di parametri / locale ma il compilatore tenta comunque di implementare uno stack di parametri di runtime e se il tuo codice non deve essere reinserito, potresti essere in grado di salvarlo spazio allocando staticamente le variabili automatiche. In alcuni casi, questo deve essere fatto manualmente; in altri casi, le direttive del compilatore possono farlo. Un'allocazione manuale efficiente richiederà la condivisione di variabili tra le routine. Tale condivisione deve essere effettuata con attenzione, per garantire che nessuna routine utilizzi una variabile che un'altra routine considera "nell'ambito", ma in alcuni casi i vantaggi della dimensione del codice possono essere significativi.

Alcuni processori hanno convenzioni di chiamata che possono rendere alcuni stili di passaggio dei parametri più efficienti di altri. Ad esempio, sui controller PIC18, se una routine accetta un singolo parametro a un byte, può essere passata in un registro; se ci vuole più di questo, tutti i parametri devono essere passati nella RAM. Se una routine accetta due parametri a un byte, può essere più efficiente "passare" uno in una variabile globale, quindi passare l'altro come parametro. Con routine ampiamente utilizzate, i risparmi possono sommarsi. Possono essere particolarmente significativi se il parametro passato tramite global è un flag a bit singolo o se di solito avrà un valore di 0 o 255 (poiché esistono istruzioni speciali per memorizzare uno 0 o 255 in RAM).

Sul ARM, l'inserimento di variabili globali che vengono spesso utilizzate insieme in una struttura può ridurre significativamente la dimensione del codice e migliorare le prestazioni. Se A, B, C, D ed E sono variabili globali separate, il codice che le utilizza tutte deve caricare l'indirizzo di ciascuna in un registro; se non ci sono abbastanza registri, potrebbe essere necessario ricaricare quegli indirizzi più volte. Al contrario, se fanno parte della stessa struttura globale MyStuff, il codice che utilizza MyStuff.A, MyStuff.B, ecc. Può semplicemente caricare l'indirizzo di MyStuff una volta. Grande vincita.

1.Se il codice si basa su molte strutture, assicurarsi che i membri della struttura siano ordinati da quelli che occupano la maggior parte della memoria al minimo.

Esempio: "uint32_t uint16_t uint8_t" invece di "uint16_t uint8_t uint32_t"

Ciò garantirà un'imbottitura minima della struttura.

2. Utilizzare const per le variabili, ove applicabile. Ciò garantirà che tali variabili siano nella ROM e non consumino RAM

Alcuni trucchi (forse ovvi) che ho usato con successo nel comprimere il codice di alcuni clienti:

1. Compatta flag in campi bit o maschere bit. Questo può essere utile poiché di solito i booleani sono memorizzati come numeri interi, sprecando così la memoria. Ciò salverà sia la RAM che la ROM e di solito non viene eseguita dal compilatore.

2. Cerca la ridondanza nel codice e usa loop o funzioni per eseguire istruzioni ripetute.

3. Ho anche salvato un po 'di ROM sostituendo molte if(x==enum_entry) <assignment>istruzioni dalle costanti con un array indicizzato, avendo cura che le voci enum potessero essere usate come indice dell'array

Se possibile, utilizzare le funzioni incorporate o le macro del compilatore anziché le piccole funzioni. Ci sono overhead di dimensioni e velocità con argomenti di passaggio e simili che possono essere risolti rendendo la funzione in linea.

Modificare le variabili locali in modo che abbiano le stesse dimensioni dei registri della CPU.

Se la CPU è a 32 bit, utilizzare le variabili a 32 bit anche se il valore massimo non supererà mai 255. Ho usato una variabile a 8 bit, il compilatore aggiungerà il codice per mascherare i 24 bit superiori.

Il primo posto che vorrei guardare è le variabili for-loop.

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

Questo potrebbe sembrare un buon posto per una variabile a 8 bit, ma una variabile a 32 bit potrebbe produrre meno codice.