Sto basando questo principalmente sugli assemblatori che ho usato - principalmente MASM, NASM e (in misura minore) TASM. Alcune delle versioni successive di TASM avevano (hanno?) Alcune funzionalità per supportare OO, ma non le ho usate molto e non sto cercando di commentarle.
Primo: la maggior parte delle lingue si è spostata verso una struttura che è almeno un po 'come un albero. Sia orientato agli oggetti, o basato sugli oggetti, o esattamente cosa, c'è un po 'definito sulle relazioni tra le diverse parti di un sistema. C'è anche un po 'di "proteggere" una parte di un sistema da "intromissione" accidentale ma altre parti (anche se la protezione può essere aggirata di solito se lo si desidera). Al contrario, il linguaggio assembly è relativamente "piatto" - la maggior parte delle relazioni tra il codice (ei dati) in diverse parti del sistema sono stabilite principalmente dalla documentazione e in misura minore dalle convenzioni di denominazione.
Il risultato è che spesso è molto più semplice accoppiare il codice molto più strettamente di quanto sarebbe ideale. I requisiti che hanno guidato la scelta del linguaggio assembly per iniziare (prestazioni più elevate, dimensioni più piccole, ecc.) Spesso premiano anche questo - aggirando le interfacce approvate e in questo modo è possibile ottenere codice più piccolo e più veloce (anche se di solito non è molto meglio in qualsiasi dimensione). Il linguaggio e gli strumenti stessi fanno molto meno per limitare quello che fai (buono o cattivo), il che pone un carico molto maggiore per i manager per prevenire problemi. Non direi che è qualitativamente diverso, ma quantitativamente è - cioè, la gestione deve lavorare per prevenire i problemi in entrambi i modi, ma nel caso del linguaggio assembly in genere richiede più (e spesso più severe) linee guida su ciò che è o non è t accettabile.
Attenuare questo è in gran parte una questione di linee guida più attente, più indicazioni da parte di personale più esperto e convenzioni di denominazione più specifiche e applicate con cura.
Il personale è un problema. I problemi che ho incontrato, tuttavia, non erano principalmente quelli che mi aspettavo. Trovare ragazzi con un po 'di personalità da "combattenti" che erano felici di saltare nel codice del linguaggio assembly era abbastanza facile. La maggior parte ha fatto un lavoro abbastanza ragionevole, nonostante una mancanza quasi totale di esperienza precedente nell'uso del linguaggio assembly.
La difficoltà che ho incontrato è stata la ricerca di personale più anziano - persone che potevano mantenere il progetto sotto almeno una parvenza di controllo, e non erano completamente abituati a lingue che avrebbero fornito (e in gran parte rafforzato) le linee guida necessarie per mantenere il codice ragionevolmente mantenibile e comprensibile.
Guardando indietro, potrei essere stato / causato alcuni dei maggiori problemi in questo senso. Posso vedere due fonti di problemi da parte mia. Innanzitutto, al momento del progetto a cui sto pensando, ho programmato principalmente in lingue di livello superiore per un po 'di tempo, e usando il linguaggio di assemblaggio solo come un'ultima risorsa. Come tale, quando l'ho usato, quasi tutti i possibili trucchi per ottenere prestazioni non erano solo fair game, ma attesi. In secondo luogo, quando avevo lavorato su alcuni sistemi scritti interamente (o principalmente) in linguaggio assembly, si trattava di alcuni project managers piuttosto ironici. All'epoca ero relativamente giovane e francamente irritato dal modo in cui gestivano le cose, quindi tendevo a fare il contrario. In retrospettiva, quello che stavano facendo era davvero importante, e non fatto solo perché erano vecchi e inflessibili (il che, sono abbastanza sicuro di come vedevo le cose in quel momento).