L'assemblaggio è ancora pertinente? [chiuso]

18

Esistono grandi differenze tra linguaggio di assemblaggio e linguaggi di livello superiore quando si tratta di programmare e / o gestire progetti? Ovviamente ci vogliono più istruzioni nel linguaggio assembly per eseguire una particolare operazione rispetto alla maggior parte degli altri linguaggi, ma ci sono differenze che influenzano il modo in cui un progetto deve (o dovrebbe) essere eseguito in base al linguaggio dell'assembly di targeting (in particolare linguaggio assembly x86 / x64) ?

Nella misura in cui ci sono differenze tra linguaggio assembly e altre lingue, sembra ragionevole intuire che almeno alcuni di questi sono vantaggi per le altre lingue. Qualcuno può segnalare svantaggi specifici del linguaggio assembly e modi per mitigare tali svantaggi?

Un esempio specifico potrebbe essere la disponibilità del personale. Qualcuno ha avuto problemi nel trovare programmatori esperti in linguaggio assembly e, in caso affermativo, quali passi si possono intraprendere per mitigare questo problema?

    
posta GlenH7 25.07.2011 - 21:29
fonte

6 risposte

25

Sì, ma non spesso.

In un certo senso, l'assembly è in realtà solo un proxy per il linguaggio macchina, quindi ovviamente puoi fare qualsiasi cosa in assembly che potresti con un linguaggio di livello superiore.

L'opposto non è sempre il caso. Ad esempio, alcuni anni fa, ho lavorato su una CPU ARM con alcuni opcode funky per modificare gli stati grafici che potevano essere utilizzati solo dalla modalità kernel. Non avrebbero alcun equivalente diretto in un linguaggio di livello superiore, e sono sicuro che la funzione nel driver del kernel di Linux per la modifica di quegli stati includesse alcuni assembly.

Nei microprocessori negli anni '80 e nei primi anni '90, se avevi del codice che dovevi eseguire molto velocemente, lo scrivesti spesso in assembly, perché un umano esperto poteva facilmente scrivere assembly più ottimizzati che la maggior parte dei compilatori C potrebbe generare. Alcuni dei primi programmi per Mac erano scritti interamente in assemblaggio, ed erano sorprendentemente veloci per l'era. Anche senza scrivere l'intero programma in assembly, ho certamente fatto la mia parte di ottimizzazione dei loop interni in C tramite assembly embedded.

Ma le cose hanno iniziato a cambiare a metà degli anni '90. Le CPU hanno iniziato a includere funzionalità come pipelining e branch branch, quindi l'ordinamento delle istruzioni più efficiente non è sempre stato ovvio per un essere umano. Peggio ancora, l'ordinamento più efficiente variava tra le CPU della stessa famiglia; ad esempio, i compilatori PowerPC offrivano in genere switch di destinazione per le serie G3, G4 e G5. Lo stesso codice oggetto verrebbe eseguito su tutti, ma funzionerebbe su una di quelle serie in modo più efficiente.

Da allora, l'ordinamento delle istruzioni è diventato progressivamente più complicato, specialmente sulle CPU più architettonicamente complesse come x86, PowerPC e SPARC. (Credo che ARM sia ancora piuttosto semplice in questo modo.) Un grande fattore aggiunto è la dimensione del codice: il codice che utilizza più cicli della CPU ma può rimanere nella CPU spesso viene eseguito molto più velocemente del codice che utilizza un minor numero di cicli della CPU ma fa scattare lentamente i recuperi della memoria . I principali compilatori moderni possono fare un lavoro molto migliore di ottimizzazione del codice su quelle CPU rispetto a un umano ragionevolmente possibile.

Non ho trovato una buona ragione per scrivere assembly in almeno 15 anni. Penso che nel 2011, gli usi principali per il montaggio sarebbero:

  • Per leggere i dump di disassemblaggio durante il debug, cosa che faccio occasionalmente anche oggi.
  • Trattare con funzioni CPU non standard, come quella modalità grafica funky.
  • Scrittura del compilatore - fornisce un formato intermedio leggibile dall'uomo per tradurre i linguaggi di livello superiore in.
risposta data 25.07.2011 - 22:55
fonte
19

Prova a programmare un microcontrollore per un "piccolo embedded": un telecomando per auto, un monitor per batteria del telefono, un controller per tastiera, un regolatore della velocità della ventola, senza utilizzare l'assemblaggio.

Mentre il confine si sposta, c'è sempre spazio per il montaggio.

15 anni fa il tuo contachilometri della bicicletta era meccanico, un forno a microonde era in circuiti analogici, il telecomando della TV era in circuiti digitali, il sintonizzatore Sat TV era scritto in assemblea, un firmware del telefono era in C e un'applet del computer era in Java.

7 anni fa un forno a microonde era in circuiti digitali, un telecomando TV era stato scritto in assemblea, il set-top box TV era scritto in C, il telefono eseguiva l'interfaccia utente basata su Java.

Al giorno d'oggi, un contachilometri della bicicletta è in circuiti digitali, un forno a microonde ottiene il firmware in assemblea, un telecomando TV ha firmware in C, TV set-top box esegue Java, il tuo telefono ha Linux.

Vuoi scommettere i prossimi 7 anni? Man mano che la tecnologia acquisisce linguaggi di controllo più avanzati, l'assemblaggio acquisisce nuovi motivi e continuerà a riceverli. Guarda cosa viene fatto oggi con circuiti meccanici o analogici. Puoi scommettere il montaggio lì in pochi anni. Il tuo interruttore della luce? Il tuo rubinetto dell'acqua? Il tuo bollitore? Lo spazzolino da denti?

Ci sarà sempre un nuovo dispositivo, apparecchio, giocattolo, oggetto di vita comune da programmare in assemblea.

    
risposta data 26.07.2011 - 11:26
fonte
8

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).

    
risposta data 25.07.2011 - 22:27
fonte
0

secondo me l'assemblaggio come piattaforma di sviluppo potrebbe non essere rilevante per l'uso quotidiano. il motivo principale di questa opinione potrebbe essere dovuto al fatto che la quantità di potenza di calcolo che viene rimossa da un determinato processo Rispetto alla quantità di tempo di sviluppo necessaria per ottimizzare lo stesso processo di solito non vale il tempo e l'energia (c'è un termine specifico per questo .. suona come uomo / ora o qualcosa ... per favore modifica se sai di cosa parlo ..) ci sono le ovvie eccezioni sopra menzionate, ma per quanto riguarda la programmazione tradizionale, l'assembly non viene usato spesso.

detto questo..assemblaggio è ancora rilevante oggi quando si apprende la programmazione nel contesto degli studi di ingegneria del software, si insegna come un linguaggio di programmazione di basso livello si sente e si comporta. andrò avanti e darò l'esempio di ciò che usiamo in classe in questi giorni. utilizziamo l'assembly pep / 8 sviluppato da Stanley Warford (Pepperdine University USA) e il suo software open source con qui . utilizzato principalmente perché virtualizza la CPU e mostra il contenuto della memoria mentre si passa attraverso il codice mentre è in esecuzione (molto utile per l'apprendimento, il debug).

Quindi, a seconda del tuo assembly di utilizzo, potrebbe essere o non essere pertinente secondo me.

    
risposta data 06.03.2012 - 21:52
fonte
0

Penso che stai chiedendo "i camion sono ancora rilevanti se abbiamo macchine?". Voglio dire, l'assemblaggio ha una vasta gamma di applicazioni ma non è così ampia come quella di programmazione di alto livello, allo stesso modo in cui ci sono molti meno camion delle automobili.

In campi come l'ottimizzazione degli algoritmi, puoi usare direttamente i registri del processore per migliorare gli algoritmi di elaborazione di immagini / video.

In campi come la crittografia puoi usarlo allo stesso modo.

Nei nuovi processori con nuove architetture (ricorda quando è stato rilasciato il microprocessore Cell), sicuramente hanno dovuto scrivere boot loader e così via in assembly (e anche con vecchi processori, ma i processori usati da molto tempo hanno un terreno molto stabile ed è difficile da migliorare).

E molti altri esempi potrebbero essere forniti, quindi dipende dal settore in cui la tua azienda è focalizzata, se la tua azienda è dedicata allo sviluppo web / mobile, è molto probabile che tu non ne abbia bisogno, ma se la tua azienda è focalizzata nei microcontrollori, nei sistemi embedded, ecc. è abbastanza probabile che sia necessario.

E la disponibilità del personale, dipende, suppongo che se chiedi in Intel, Qualcomm, ... devono avere una lista di programmatori di assemblaggio (è come se chiedi sul posto di lavoro "quanti camionisti sono qui intorno ? "Non penso molto, ma non significa che non ci siano in altri luoghi. Cosa succede se chiedi" quanti automobilisti sono qui intorno? ").

    
risposta data 06.07.2015 - 10:54
fonte
-3

Se davvero vuoi sapere perché l'assembly di apprendimento è la migliore scommessa. Ecco i motivi.

  1. Non c'è bisogno di imparare l'assembly, se hai intenzione di programmare su Visual Basic e su MS.
  2. Non è necessario imparare il montaggio, se non si devono fare seri gadget per microcontrollori.
  3. Non c'è bisogno di imparare il montaggio, se hai a disposizione un patrimonio di memoria mentre lavori sul microcontrollore (dio ti aiuta mentre si interfaccia la memoria con il microcontrollore)
  4. Non c'è bisogno di imparare il montaggio, se non vuoi che dio abbia il potere sul tuo microcontrollore / microprocessore.
  5. Non sapere che l'assemblaggio è come conoscere l'iceberg. Puoi vedere il 25% di ciò che la tua e la tua capacità di micros e il 75% non saprai mai o capirai
  6. Prova a eseguire il Kolibris OS completamente scritto in Assembly !!! Hai visto un sistema operativo che si avvia in meno di 5 secondi e l'applicazione inizia a funzionare con 1 sec di clic del mouse.
  7. I compilatori moderni hanno funzioni generiche nel back-end e quindi il codice finale generato sarebbe pesante rispetto all'assemblaggio.

L'assemblaggio è come la Natasha Romanoff dei Vendicatori. È un fascino e una magia. In primo luogo, ti morderà ma credimi non dimenticherai mai il gusto.

    
risposta data 06.07.2015 - 04:36
fonte

Leggi altre domande sui tag