L'Assemblea è ancora rilevante? [chiuso]


18

Esistono differenze sostanziali tra il linguaggio assembly e le lingue di livello superiore quando si tratta di codifica e / o gestione di progetti? Ovviamente sono necessarie più istruzioni nel linguaggio assembly per eseguire un'operazione particolare rispetto alla maggior parte delle altre lingue, ma ci sono differenze che influenzano il modo in cui un progetto deve (o dovrebbe) essere eseguito in base al linguaggio assembly di targeting (in particolare linguaggio assembly x86 / x64) ?

Nella misura in cui esistono differenze tra il linguaggio assembly e altre lingue, sembra ragionevole supporre che almeno alcuni di questi siano vantaggi per le altre lingue. Qualcuno può indicare specifici svantaggi del linguaggio assembly e modi per mitigare tali svantaggi?

Un esempio specifico sarebbe la disponibilità del personale. Qualcuno ha avuto problemi a trovare programmatori esperti di linguaggio assembly e, in caso affermativo, quali misure possono essere prese per mitigare questo problema?


Perché qualcuno dovrebbe scrivere un progetto completo solo in linguaggio assembly oggi? Oppure stai chiedendo un ambiente in lingua mista, come si usa oggi l'assembly?
Martin Vilcans,

6
Si noti che ci sono aree di non-[PC|web|enterprise]programmazione, in cui l'Assemblea è predominante o molto popolare. Sto parlando di microcontroller, automazione industriale o robotica. Certo, ci sono lingue di alto livello anche in queste aree, ma vedi molto l'Assemblea.
Mchl

1
@Mchl: questi progetti non sono realizzati in C (o anche in C ++) e possibilmente assemblati? Avrei indovinato che è molto raro usare esclusivamente assembly.
Martin Vilcans,

1
In realtà nell'automazione industriale è possibile incontrare un intero ramo di lingue che semplicemente non esistono al di fuori di quel campo. Parte di ciò deriva dalle differenze nell'hardware (l'architettura di Harvard al contrario dell'architettura von Neumann a cui siamo così abituati). così come dalla storia di rendere questi controller accessibili agli elettricisti, che erano abituati a lavorare con interruttori e relè. È così che LD ( en.wikipedia.org/wiki/Ladder_logic ) prende vita, che in realtà è un'interpretazione grafica dell'assemblaggio. Vedi l'articolo collegato per alcuni altri linguaggi usati nell'automazione.
Mchl

2
Ho un piccolo programma di installazione che supporto ora che è in assembly. È stato facile scrivere in assembly (con l'API di Windows) come qualsiasi altra cosa, quindi perché no? Ho anche un'interfaccia swiper per carte di credito scritta in assembly. Iniziato con linguaggi di alto livello, ma ho avuto così tante difficoltà a farlo funzionare che ho riscritto in assemblea per ottenere un migliore controllo di tutti i bit che scorrono ...
Brian Knoblauch,

Risposte:


25

Sì, ma non spesso.

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

Il contrario non è sempre il caso. Ad esempio, alcuni anni fa, ho lavorato su una CPU ARM che aveva alcuni codici opachi funky per cambiare gli stati grafici che potevano essere utilizzati solo dalla modalità kernel. Non avrebbero equivalenti diretti in un linguaggio di livello superiore, e sono sicuro che la funzione nel driver del kernel Linux per cambiare quegli stati includesse un po 'di assembly.

Sui microprocessori negli anni '80 e nella prima metà degli anni '90, se avessi del codice che ti serviva per correre molto velocemente, lo scrivevi spesso in assembly, perché un essere umano esperto poteva facilmente scrivere un assembly più ottimizzato rispetto alla maggior parte dei C i compilatori potrebbero generare. Alcuni dei primi programmi per Mac furono scritti interamente in assemblea e furono sorprendentemente veloci per l'epoca. Anche senza scrivere l'intero programma in assembly, ho sicuramente fatto la mia parte per ottimizzare i loop interni in C tramite assembly incorporato.

Ma le cose hanno iniziato a cambiare a metà degli anni '90. Le CPU hanno iniziato a includere funzionalità come pipeline e previsione dei rami, quindi l'ordinamento delle istruzioni più efficiente non era sempre ovvio per un essere umano. Peggio ancora, l'ordinamento più efficiente variava tra le CPU della stessa famiglia; ad esempio, i compilatori PowerPC in genere offrivano switch target 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ù complesse dal punto di vista architettonico 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 che può rimanere nella cache della CPU verrà spesso eseguito molto più velocemente del codice che utilizza meno cicli della CPU ma innesca rallentamenti della memoria . I principali compilatori moderni possono fare un lavoro di gran lunga migliore nell'ottimizzare il codice su quelle CPU rispetto a quanto ragionevolmente può fare un essere umano.

Non ho trovato un buon motivo per scrivere un'assemblea da almeno 15 anni. Penso che nel 2011 gli usi principali dell'assemblaggio sarebbero:

  • Leggere le discariche di smontaggio durante il debug, cosa che a volte faccio anche oggi.
  • Trattare con funzionalità della CPU non standard, come quella modalità grafica funky.
  • Scrittura del compilatore: fornisce un formato intermedio leggibile dall'uomo per tradurre lingue di livello superiore.

1
E anche la tua ragione n. 3 sta iniziando a scomparire con i compilatori che prendono di mira un framework di compilatore di alto livello come LLVM, nanojit o libjit o qualcosa come JVM, CIL, Parrot, Rubinius o Neko bytecode.
Jörg W Mittag,

A volte è ancora necessario fare un po 'di SSE2 nel lavoro grafico / video. Anche se benchmark prima contro TBB / OMP!
Martin Beckett,

@Martin: OMP è ortogonale a SSE2. (presupponendo buone pratiche di layout dei dati)
rwong

@rwong - ma il processo è ancora, 1, scopri che è troppo lento. 2, spero che OMP / TBB acceleri abbastanza. 3, ricorri a mano scrivendo la versione SSE2! (in ordine di dolore)
Martin Beckett,

2
Ad esempio, l'intero Roller Coaster Tycoon è stato scritto in assemblaggio (meno la grafica che è stata fatta in c) ed è stato incredibilmente potente per il suo tempo. Centinaia di singoli IA che agiscono in modo indipendente, quasi senza soluzione di continuità, quando la maggior parte dei giochi aveva alcuni sprite di 16x16 pixel che eseguivano movimenti predefiniti. Mi piace sempre usarlo per mostrare il potere dell'assemblaggio.
Appunto

19

Prova a programmare un microcontrollore per un "piccolo incorporato": un telecomando per allarme auto, un monitor batteria del telefono, un controller tastiera, un regolatore di velocità della ventola, senza utilizzare il gruppo.

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

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

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

Al giorno d'oggi, un contachilometri per biciclette è in circuiti digitali, un forno a microonde ottiene il firmware nell'assemblaggio, un telecomando TV ha il firmware in C, il decoder TV funziona con Java, il tuo telefono ha Linux.

Vuoi scommettere sui prossimi 7 anni? Man mano che più tecnologia ottiene linguaggi di controllo più avanzati, l'assemblaggio acquisisce nuovi motivi e continuerà a ottenerli. Guarda cosa viene fatto oggi con circuiti meccanici o analogici. Puoi scommettere sull'assemblaggio in pochi anni. Il tuo interruttore della luce? Il tuo rubinetto dell'acqua? Il tuo bollitore? Il tuo spazzolino?

Ci sarà sempre un nuovo dispositivo, apparecchio, giocattolo, oggetto di vita comune da programmare nell'assemblaggio.


3
buona risposta. Quante persone preferirebbero pagare il doppio per qualcosa che le batterie durano la metà del tempo solo perché java o qualcosa è stato usato come piattaforma di sviluppo? Guarda groupon e tutti gli altri modi in cui la gente cerca di risparmiare denaro, osserva il movimento verde che risparmia risorse. Perché aumentare i costi e accendere tutti i prodotti embedded solo per evitare il montaggio?
old_timer

1
Hai dimenticato di aggiungere che ora i computer eseguono Javascript (Chromebook). Per me quella progressione è piuttosto triste ma vera.
Hawken,

A partire dal 2017, la CIA entra nella tua TV con Linux, i segnali da Java in esecuzione sulle chiavi dell'auto possono essere falsificati, chiunque può connettersi tramite WIFI al firmware C ++ di una fotocamera dildo , uno spazzolino da denti ha ottenuto un exploit remoto nel 2013, ma per fortuna ancora auricolari con cancellazione del rumore creata nel lavoro di assemblaggio. Sebbene l'assemblaggio perda qualsiasi posizione come controller di livello superiore , spostandosi invece in sottocomponenti. I tuoi tapparelle già eseguono Java, ma quella scheda di controllo Java comunica con il controller del motore per tapparelle che funziona con assembly.
SF.

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 in qualche modo simile ad 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 bel po 'di "proteggere" una parte di un sistema da "interferenze" accidentali, ma altre parti (anche se la protezione può di solito essere aggirata se si desidera). Al contrario, il linguaggio assembly è relativamente "piatto" - la maggior parte delle relazioni tra il codice (e i dati) in diverse parti del sistema sono stabilite principalmente dalla documentazione e, in misura minore, dalle convenzioni di denominazione.

Il risultato di ciò è che spesso è molto più facile accoppiare il codice molto più strettamente di quanto sarebbe l'ideale. I requisiti che hanno guidato la scelta del linguaggio di assemblaggio con cui iniziare (prestazioni più elevate, dimensioni più ridotte, ecc.) Spesso premiano anche questo, bypassando le interfacce approvate e in tal modo è spesso 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 ciò che fai (bene o male), il che comporta un onere molto maggiore per i manager per prevenire problemi. Non direi che è qualitativamente diverso, ma quantitativamente lo è - vale a dire, la direzione deve lavorare per prevenire i problemi in entrambi i modi, ma nel caso del linguaggio assembly generalmente richiede più linee guida (e spesso più rigide) su ciò che è o non è t accettabile.

La mitigazione è in gran parte una questione di linee guida più attente, più guida da parte di personale più esperto e convenzioni di denominazione più specifiche e attentamente applicate.

Il personale è un problema. I problemi che ho riscontrato, tuttavia, non erano principalmente quelli che mi aspettavo. Trovare ragazzi con un po 'di personalità "combattente" che erano felici di saltare nel codice del linguaggio assembly è stato abbastanza facile. La maggior parte ha svolto un lavoro abbastanza ragionevole, nonostante una mancanza quasi totale di esperienza precedente nell'uso del linguaggio assembly.

La difficoltà che ho incontrato è stata quella di trovare più personale senior - persone che potevano mantenere il progetto sotto almeno una parvenza di controllo e non erano completamente abituate a linguaggi che avrebbero fornito (e in gran parte applicato) le linee guida necessarie per mantenere il codice ragionevolmente mantenibile e comprensibile.

Guardando indietro, potrei essere stato / aver causato alcuni dei maggiori problemi al riguardo. Vedo due fonti di problemi da parte mia. Innanzitutto, al momento del progetto a cui sto pensando, avevo programmato per un po 'di tempo principalmente in linguaggi di livello superiore e usando solo il linguaggio assemblycome ultima opzione. In quanto tale, quando l'ho usato, quasi ogni possibile trucco per ottenere prestazioni non era solo un gioco equo, ma previsto. In secondo luogo, quando avevo lavorato su alcuni sistemi scritti interamente (o principalmente) in linguaggio assembly, era sotto alcuni gestori di progetto piuttosto a pugni. All'epoca ero relativamente giovane, e francamente mi risentivo per il 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 poco flessibili (il che, sono abbastanza sicuro di come vedevo le cose in quel momento).


Ho bei ricordi di assemblatori TASM e Orca / M =)
Patrick Hughes,

0

a mio avviso, 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 computazionale 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 (esiste un termine specifico per questo .. sembra che man / hour o qualcosa del genere ... per favore modifica se sai di cosa parlo ..) ci sono le ovvie eccezioni sopra menzionate ma per quanto riguarda la programmazione tradizionale non si usa spesso.

detto questo..assemblaggio è ancora rilevante oggi quando si impara la programmazione nel contesto di studi di ingegneria del software, insegna come si presenta e si comporta un linguaggio di programmazione di basso livello. Continuerò e darò l'esempio di ciò che usiamo in classe in questi giorni. usiamo l'assemblaggio pep / 8 sviluppato da Stanley Warford (Pepperdine University USA) e il suo software open source qui fornito . usato principalmente perché virtualizza la cpu e mostra il contenuto della memoria mentre si scorre il codice mentre è in esecuzione (molto utile per l'apprendimento, il debug).

Quindi, a seconda del tuo assemblaggio di utilizzo, a mio avviso, potrebbero non essere rilevanti.


0

Penso che tu stia chiedendo "i camion sono ancora rilevanti se abbiamo auto?". Voglio dire, il montaggio ha una gamma molto ampia di applicazioni, ma non così ampia come la programmazione di alto livello, allo stesso modo in cui ci sono molti meno camion che automobili.

In campi come l'ottimizzazione degli algoritmi, è possibile utilizzare 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 dovevano scrivere boot loader e così via nell'assemblaggio (e anche con vecchi processori, ma i processori usati da molto tempo hanno un terreno molto stabile ed è difficile da migliorare esso).

E potrebbero essere forniti molti altri esempi, quindi dipende dal campo 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 sui microcontrollori, è molto probabile che siano necessari sistemi integrati, ecc.

E la disponibilità del personale, dipende, suppongo che se chiedi a Intel, Qualcomm, ... devono avere un grande elenco di programmatori di assemblaggio (è come se chiedessi sul posto di lavoro "quanti camionisti ci sono qui?" non pensare molto, ma ciò non significa che non ci siano altri posti. Cosa succede se chiedi "quanti automobilisti ci sono qui?").


-3

Se vuoi davvero sapere perché imparare l'assemblaggio è la soluzione migliore. Ecco i motivi.

  1. Non c'è bisogno di imparare l'assemblaggio, se hai intenzione di programmare su Visual Basic e roba MS.
  2. Non è necessario apprendere l'assemblaggio, se non è necessario creare gadget di microcontrollori seri.
  3. Non c'è bisogno di imparare l'assemblaggio, se hai un patrimonio di memoria a tua disposizione mentre lavori al microcontrollore (dio ti aiuta nell'interfaccia della memoria con il microcontrollore)
  4. Non c'è bisogno di imparare l'assemblaggio, se non vuoi che Dio abbia il potere sul tuo microcontrollore / microprocessore.
  5. Non conoscere l'assemblea è come conoscere l'iceberg. Puoi vedere il 25% di ciò che la tua e la tua capacità di micros e il 75% che non conoscerai o capirai mai
  6. Prova a eseguire 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 secondo di clic del mouse.
  7. I compilatori moderni hanno funzioni di uso generale nel backend e quindi il codice finale generato sarebbe pesante rispetto a Assembly.

L'assemblea è come la Natasha Romanoff dei Vendicatori. È un incanto e una magia. In primo luogo, ti morderà ma fidati di me non dimenticherai mai il gusto.


1
questo non sembra offrire nulla di sostanziale rispetto ai punti formulati e spiegati nelle precedenti 5 risposte
moscerino del
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.