Come si struttura un progetto in linguaggio assembly?

5

Quindi, seguo un corso MIPS dopo il ritorno a scuola; e ci stiamo avvicinando al punto in cui iniziamo il nostro progetto finale.

Sono sempre stato uno per progetti grandi e ben strutturati: un sacco di strumenti di supporto, zone ben separate di controllo e preoccupazione all'interno del progetto, test approfonditi, così via e così via. Sfortunatamente, non conosco molto, né alcuno strumento per il codice del linguaggio assembly.

All'inferno, al massimo, non so come comporre più file (o capovolgerli in testa: come separare gruppi di procedure in file e interferenza tra loro). C'è un pratica standard (ish) per queste cose?

In assenza di altre informazioni, sospetto che possa essere necessario utilizzare il preprocessore C (o m4 ): P per comporre componenti; ma oltre a questo, come suggeriresti di strutturare un progetto più grande?

Also welcome: Any advice on writing relatively maintainable / shareable, clean, assembly-language code, beyond “use 8-space hard-tabs.”

    
posta ELLIOTTCABLE 09.06.2016 - 10:02
fonte

2 risposte

4

Un libro potrebbe essere scritto su questo argomento. Scommetto che alcuni hanno. . .

È difficile rispondere perché ogni catena di strumenti ha i suoi punti di forza, i suoi limiti e le sue peculiarità. Devo aver strutturato diversi progetti in una mezza dozzina di modi diversi, ma menzionerò i due che ho usato di più.

Per quasi tutte le tecniche, è necessario suddividere adeguatamente i componenti. L'obiettivo è di rendere ogni modulo 1) una scatola nera ben definita e documentata che possa essere facilmente utilizzata senza dover scavare nel codice, e 2) abbastanza generale da poter essere riutilizzata così come è nei progetti successivi. Tutti i miei progetti utilizzano i miei moduli "matematica", "dispatcher" e "timer". Quindi ci possono essere moduli per SPI, I2C, SCI, PWM ecc. La maggior parte delle volte questa separazione delle funzionalità è piuttosto intuitiva.

La prima tecnica è assemblare ogni modulo separatamente e poi metterli tutti in una libreria di oggetti ("oggetto" come in codice macchina, non "oggetto" come nella programmazione orientata agli oggetti). Quindi, quando si scrive il programma principale, si effettuano solo chiamate alle routine della libreria e il linker includerà automaticamente i moduli oggetto necessari nell'eseguibile.

Ma alcune catene di strumenti o non supportano bene le librerie di oggetti, o ne fanno un laborioso colloquio per creare e mantenere. In questa situazione, "includo" ciascun modulo sorgente necessario alla fine del programma principale, e l'assemblatore crea un modulo oggetto di grandi dimensioni (che facilita il collegamento del linker).

In entrambi i casi, il programma principale inizia con un elenco su "include" per le definizioni dell'hardware e le definizioni delle macro (io uso molti LOT di macro, sia per la leggibilità che per la portabilità). Quindi aggiungo il codice principale. Se sto usando una libreria di oggetti, allora è tutto. Se sto usando una libreria di sorgenti, quindi termino con un elenco di "include" per i moduli di origine richiesti.

Potrei andare avanti, ma è tardi. . .

    
risposta data 09.06.2016 - 11:12
fonte
-1

Ho scritto e gestito un pacchetto commerciale di dimensioni ragionevoli in linguaggio assembly (40.000 righe di codice a 16 bit e 35.000 righe di 8 bit). Ha funzionato bene e ha avuto zero bug.

Le uniche comunicazioni tra moduli possibili erano che un simbolo (un indirizzo in codice programma o un indirizzo dati in memoria) potesse essere dichiarato pubblico in un modulo e esterno in un altro. Non mi sono preoccupato delle librerie perché assemblatori e linker sono abbastanza veloci comunque, quindi compilare e collegare ogni cosa ogni volta ha funzionato bene.

I file header sono stati usati per definire le costanti, ma potrebbero anche essere stati usati per dichiarare simboli esterni.

Questa è la meccanica di ciò. Per quanto riguarda la scelta di cosa dividere in quale modulo sorgente, è la programmazione come arte letteraria e devi capire cosa funziona meglio per te. Avevo uno strato di routine di utilità (anche aritmetiche) in basso, e poi divisioni verticali per diverse aree di funzionalità.

La libertà di assemblatore è allo stesso tempo liberatoria e impegnativa, ma è un'opportunità senza precedenti per sviluppare il tuo stile.

    
risposta data 09.06.2016 - 18:30
fonte