Risposte:
La densità del codice si riferisce vagamente a quante istruzioni a microprocessore sono necessarie per eseguire un'azione richiesta e a quanto spazio occupa ciascuna istruzione. In generale, meno spazio occupa un'istruzione e più lavoro per istruzione può fare un microprocessore, più denso è il suo codice.
Ho notato che hai taggato la tua domanda con il tag 'arm'; Posso illustrare la densità del codice usando le istruzioni ARM.
Supponiamo che tu voglia copiare un blocco di dati da una posizione in memoria a un'altra. Concettualmente, il tuo codice di alto livello sarebbe simile a questo:
void memcpy(void *dest, void *source, int count_bytes)
{
char *s, *d;
s = source; d = dest;
while(count_bytes--) { *d++ = *s++; }
}
Ora un semplice compilatore per un semplice microprocessore può convertirlo in qualcosa del tipo seguente:
movl r0, count_bytes
movl r1, s
movl r2, d
loop: ldrb r3, [r1]
strb [r2], r3
movl r3, 1
add r1, r3
add r2, r3
sub r0, r3
cmp r0, 0
bne loop
(il mio braccio è un po 'arrugginito, ma hai l'idea)
Ora questo sarebbe un compilatore molto semplice e un microprocessore molto semplice, ma dall'esempio si può vedere che stiamo osservando 8 istruzioni per iterazione del loop (7 se spostiamo il '1' in un altro registro e spostiamo il carico al di fuori del ciclo). Non è per niente denso. Anche la densità del codice influisce sulle prestazioni; se i tuoi loop sono più lunghi perché il codice non è denso, potresti aver bisogno di più cache di istruzioni per contenere il loop. Più cache significa un processore più costoso, ma poi una complessa decodifica delle istruzioni significa più transistor per decifrare l'istruzione richiesta, quindi è un classico problema di ingegneria.
ARM è piuttosto gentile da questo punto di vista. Ogni istruzione può essere condizionata, la maggior parte delle istruzioni può incrementare o diminuire il valore dei registri e la maggior parte delle istruzioni può facoltativamente aggiornare i flag del processore. Su ARM e con un compilatore moderatamente utile, lo stesso loop potrebbe assomigliare a questo:
movl r0, count_bytes
movl r1, s
movl r2, d
loop: ldrb r3, [r1++]
strb [r2++], r3
subs r0, r0, 1
bne loop
Come puoi vedere, il ciclo principale ora contiene 4 istruzioni. Il codice è più denso perché ogni istruzione nel ciclo principale fa di più. Questo in genere significa che puoi fare di più con una determinata quantità di memoria, perché meno viene utilizzata per descrivere come eseguire il lavoro.
Ora il codice ARM nativo aveva spesso la lamentela che non era super denso; ciò è dovuto a due ragioni principali: in primo luogo, 32 bit è un'istruzione terribilmente "lunga", quindi molti bit sembrano essere sprecati per istruzioni più semplici, e in secondo luogo, il codice è stato gonfiato a causa della natura di ARM: ogni istruzione è 32 bit lunghi, senza eccezioni. Ciò significa che esiste un numero elevato di valori letterali a 32 bit che non è possibile caricare in un registro. Se volessi caricare "0x12345678" in r0, come posso codificare un'istruzione che non contiene solo 0x12345678, ma descrive anche "carica letterale in r0"? Non sono rimasti bit per codificare l'operazione effettiva. L'istruzione letterale del carico ARM è una piccola bestia interessante e anche l'assemblatore ARM deve essere un po 'più intelligente dei normali assemblatori, perché deve "catturare"
Ad ogni modo, per rispondere a questi reclami, ARM ha ideato la modalità Thumb. Invece di 32 bit per istruzione, la lunghezza dell'istruzione è ora di 16 bit per quasi tutte le istruzioni e di 32 bit per i rami. Ci sono stati alcuni sacrifici con la modalità Thumb, ma in generale questi sacrifici erano facili da fare perché Thumb ti ha fatto ottenere un miglioramento del 40% nella densità del codice semplicemente riducendo la lunghezza delle istruzioni.
La "densità di codice" di un set di istruzioni è una misura di quanta roba è possibile ottenere in una determinata quantità di memoria del programma o di quanti byte di memoria del programma è necessario per memorizzare una determinata quantità di funzionalità.
Come ha sottolineato Andrew Kohlsmith, anche sulla stessa MCU, compilatori diversi possono ottenere densità di codice diverse.
Ti potrebbe piacere leggere "Insetti del mondo dei computer" di Miro Samek, che mette a confronto una varietà di MCU.