2009-04-16 14 views
5

Nella mia università la classe Assembly Programming (x86 e MIP) sta volgendo al termine.Quali sono alcuni modi in cui è possibile gestire progetti di linguaggio assembly su larga scala?

Ho apprezzato molto il mio lavoro in assemblea e mi piacerebbe davvero continuare a lavorarci. Penseresti che dover fare tutto da solo sarebbe un trascinamento, ma ho scoperto che c'è un livello di trasparenza che non riesco a ottenere con linguaggi di livello superiore.

Le cose generalmente funzionano come mi sarei aspettato, perché ho eseguito il codice macchina per farle accadere. Non c'è magia.

Tuttavia, a scuola il programma di assemblaggio più lungo che ho scritto era di 2-3 pagine.

Recentemente ho letto di Roller Coaster Tycoon essere scritto da un singolo sviluppatore, in assembly.
alt text http://i.d.com.com/i/dl/media/dlimage/15/06/92/150692_large.jpeg

Ho difficoltà a immaginare come qualcuno possa mantenere un grande progetto in assemblea.

In questo momento sto faticando a fare il salto da programmi di assemblaggio di 2-3 pagine a qualcosa di un po 'più di scala. Anche sul mio calcolatore Ti-83 le persone hanno scritto cloni di Mario/Zelda in assemblaggio che devono essere tremendamente complessi!

Ci devono essere alcuni strumenti, IDE e metodi più belli per la gestione di grandi progetti di assiemi x86 che lo rendono almeno in qualche modo gestibile.

Cosa sono?

risposta

2

Conosco persone che lavorano con l'assemblatore (non Intel). Hanno creato una vasta libreria di macro in modo che possano usarla quasi come se fosse un linguaggio di alto livello.

Per creare qualcosa come una libreria macro, iniziare in modo semplice. Raggruppando le costruzioni usate spesso in una singola macro. Alla fine sarai in grado di creare funzionalità più complesse.

2

Non proprio la risposta alla tua domanda, ma in molti scenari del mondo reale, le applicazioni sono scritte in una lingua superiore utilizzando gli idiomi comuni a quella lingua e usano solo un po 'di linguaggio assembly in cui le prestazioni o le esigenze hardware richiedono. Questo è probabilmente l'unico approccio ragionevole per i progetti reali, perché il linguaggio assembly non è produttivo quanto altri linguaggi, in termini di ottenere il computer per fare di più per ogni ora impiegata a programmarlo.

Detto questo, tutti gli strumenti e le tecniche per la gestione di un progetto in qualsiasi altra lingua si applicano allo stesso modo al linguaggio assembly. Controllo del codice sorgente, TDD, Specifiche del progetto, nomi significativi per identificatori, Separazione di preoccupazioni, modelli di progettazione orientati agli oggetti (è possibile avere design orientato agli oggetti senza un linguaggio orientato agli oggetti) si applicano allo stesso modo al linguaggio assembly come a C# o PHP

+0

"nomi significativi per identificatori" A meno che la mia comprensione di quale linguaggio assembly sia lontana (cosa che potrebbe benissimo essere) non si fa semplicemente riferimento alle locazioni di memoria e ai registri cpu direttamente? Come si ottengono nomi significativi da questo? – Davy8

+0

È raro utilizzare gli indirizzi di memoria. Generalmente l'assemblatore li lega alle variabili. –

+0

ah, non sapevo che potessi dare nomi variabili in assembly – Davy8

1

Mi sono sempre comportato come nei linguaggi di alto livello. Scrivilo in moduli che sono collegati insieme per formare il runtime.

2

L'unico progetto moderno interamente scritto in assembly che so se è FASM (il mio assemblatore preferito).

Alcuni assemblatori supportano i costrutti di alto livello e, se il motore macro è valido, è possibile scrivere il proprio. personalmente trovo questo inutile; se voglio costrutti di alto livello e per capire cosa faccio, uso C o C++. (Non penso che siano un buon linguaggio per gestire grandi progetti, però).

Uso solo l'assemblaggio quando necessario o per l'apprendimento.

Se si vuole scrivere un progetto in assemblea, tenere a mente che:

  • Probabilmente non saranno molte persone che vogliono aiutare voi con il vostro progetto, anche lo trovano interessante. Poche persone come l'assemblaggio e il tuo codice devono essere molto ben commentati se ti aspetti che qualcuno lo capisca.
  • L'assemblaggio non è portatile. Anche per passare dal PC a 32-bit a 64-bit devi sostanzialmente riscrivere tutto.
  • L'argomento "assembly is faster" non è più valido.
5

programmi di montaggio larga scala vengono gestiti come qualsiasi altro programma - ben partizionato blocchi funzionali con chiaro interfacce. Poiché stai lavorando in assembly, le tue interfacce saranno limitate a cose presenti nel file di registro o nello stack. In definitiva, è necessario avere un buon progetto piano prima dell'implementazione effettiva. Devi essere chiaro su cosa scrivere e come scriverlo.

Detto questo, se ti piace il montaggio, c'è un altro modo per essere in grado di dedicarti alla tua passione senza scrivere effettivamente codice assembly - puoi scrivere in C o C++ e vedere come il codice viene compilato per il montaggio. Quindi, scrivi la stessa cosa in un modo diverso e capisci come questo cambia l'assemblea. Di conseguenza, sarai presto in grado di pensare come un compilatore e scrivere codice altamente ottimale.

In entrambi i casi, sapere come funzionano le cose in assemblaggio alla fine ti renderà un programmatore migliore.

3

Macro, funzioni e librerie. Ci vogliono anni per sviluppare il tuo da zero, quindi cerca le risorse dell'assembler x86 e affidati agli altri - ci sono ancora molte persone che stanno facendo lo sviluppo dell'assemblaggio attivo per il PC.

Un membro attivo della comunità di montaggio è Steve Gibson, ha un sacco di link a buone risorse per la programmazione assembly qui:

http://www.grc.com/smgassembly.htm

2

In cima a ciò che è già stato detto, dovrei menzionare literate programming; Ho scritto un'applicazione che era dell'ordine di 20KLOC di assembly ARM (non enorme, ma non insignificante), e ho trovato la strutturazione del codice con noweb estremamente utile.

Questo mi ha permesso di suddividere il codice in piccoli pezzi concettuali, anche quando diversi pezzi dovevano essere combinati insieme/srotolati/eccetera per motivi di prestazioni. Inoltre ha reso molto più semplice per gli altri programmatori capire quello che avevo scritto, in particolare i motivi per cui ho preso alcune decisioni sottili (ad esempio, decidendo quale operando dovrebbe essere il primo in un multiplo basato sulla dimensione prevista degli operandi).

Problemi correlati