Ciao, questo è Amanullah.
Quindi, se avete visto che il software che utilizzerà linguaggi compilati come C non è indipendente dalla
piattaforma, non guardate solo gli interpreti che sono solo un problema di dipendenza dalla piattaforma, ma come alcune altre limitazioni.
È una caratteristica interessante ea volte anche gli ingegneri senior, ma non sanno come funzionano gli
interpreti.
Ma non sarebbe il caso per noi.
Sappiamo che in un codice di compilazione il codice macchina generato dal compilatore sul codice macchina generato non
viene eseguito separatamente dalla C. P. una lingua interpretata sembra diversa.
In un linguaggio interpretato abbiamo un interprete che è un programma che esegue direttamente il codice
sorgente.
Cioè non esiste una compilazione separata I una fase di esecuzione come nel caso del linguaggio compilato.
Come puoi vedere qui nell'interprete è il codice sorgente un'uscita è il risultato dell'esecuzione di quella fonte o
così puoi vedere la somiglianza tra un interprete e SEP ACP che trasforma il codice macchina in risultati mentre un
codice sorgente Doan di interprete nella sottomissione di dualismi il codice dice quindi il set di istruzioni per la
s. p.
Bene bene.
Così è il set di istruzioni per l'interprete.
Solo che quell'interprete è anche un programma e deve essere eseguito.
Quindi CPQ esegue l'interprete, un interprete esclude internamente il codice sorgente.
Quindi l'interprete non è nient'altro che una macchina virtuale che lo simula Sibiu che è solo un b b esigente manuale di linguaggio
macchina che usa il fetch ed è un buon ciclo.
Un interprete esegue anche le istruzioni nel codice sorgente in modo simile a quanto potrebbe fare un ciclo.
Diamo un'occhiata a come i computer recuperano ed eseguono i libri del ciclo.
La finzione è un buon psico è l'operazione più fondamentale di un computer che ogni programmatore deve sapere.
Nel caso in cui non si abbia familiarità con questa breve discussione dovrebbe essere utile.
Ora qui abbiamo una memoria CPO.
Sotto questo programma per ottenere un buon risultato quando il programma viene eseguito o avviato il programma viene semplicemente caricato in
memoria e sappiamo che un programma è un codice macchina ed è fondamentalmente una sequenza
di istruzioni in cui ogni istruzione è semplicemente una sequenza di zero e uno successivo CPQ recupera un'istruzione da loro.
Non nascosto che e nel processo può anche adattarsi a qualsiasi dato necessario per uscire dall'istruzione qualsiasi dato generato dall'esecuzione della build di istruzioni essere e
tornare con una memoria C. P. che recupera la prossima istruzione
su esecutivo.
Quindi il ciclo continua fino a quando tutte le istruzioni del programma sono state eseguite.
Quindi, in pratica, Scipio recupera un ciclo di vita operativo.
Non letterali prendi interpreti ed è un buon retaggio di Buk anche l'interprete di Buhl recupera le sue
istruzioni dalla memoria di Hulver, un interprete skees l'istruzione è fondamentalmente una dichiarazione nel codice sorgente.
Comprende quindi ciò che è necessario per eseguire questa affermazione.
E questi passaggi sono anche fatti dal compilatore il prossimo passo sarebbe una buona istruzione del programma.
Ed ecco la cosa interessante
L'interprete mantiene la libreria fuori dal codice macchina compilato ed esegue semplicemente il codice macchina
compilato appropriato che corrisponde all'istruzione del programma.
Quindi l'interprete non sta generando codice macchina, ma semplicemente usa il proprio codice macchina compilato per realizzare
ciò che la sorgente Blorb rileva che effettivamente guarda un esempio.
Qui abbiamo un'istruzione X nel codice sorgente sotto interprete esegue un codice compilato corrispondente dalla sua libreria
che è una versione di codice macchina di questo blocco di codice che vedrai qui.
Il codice sta recuperando i numeri per aggiungere un po 'di memoria e Dennis per svolgere l'attività.
E finalmente sta iniziando a rimettere in memoria.
Quindi, ancora una volta interpretor non sta generando codice macchina, ma usa la sua libreria fuori dalla macchina compilata.
Uno dei principali vantaggi dell'interprete è il nero degli indipendenti, come si può vedere in
questa illustrazione, lo stesso codice sorgente può essere eseguito su qualsiasi dorsale, il solo requisito è installare un interprete specifico
per il buco nero.
Si presenta con un linguaggio compilato che non siamo riusciti a raggiungere l'indipendenza di casa.
Questo perché invece del codice sorgente stavamo usando un codice macchina che era nero dall'approfondimento.
Quindi è una macchina catturata in gruppi attivi.
È specifico per la piattaforma su cui è stato generato.
Pertanto, la piattaforma di destinazione su cui deve essere eseguito il codice macchina potrebbe avere un set di attributi diverso
sotto il codice macchina che non riuscirebbe ad eseguire.
Ma con un linguaggio interprete stiamo eseguendo il codice sorgente identico indipendentemente dalla piattaforma su
cui è scritto.
Questo è bloccato da indipendente.
È solo che l'interprete sulla piattaforma di destinazione garantisce che il blocco da codice
sorgente indipendente venga eseguito senza problemi.
Ora diamo un'occhiata ai pro e ai contro. Se un interprete voleva che un interprete
includesse l'indipendenza dalla piattaforma, come abbiamo appena visto Max che non è completato.
Questa è l'esecuzione di un programma può fermarsi immediatamente.
Penso che uno dei principali vantaggi di non avere la fase di completamento sia che consentirebbe aggiornamenti più semplici,
ad esempio in alcuni dei miei progetti.
Ci sono stati casi in cui ho dovuto correggere bug nel codice javascript sui server di produzione. Dallas crep è
un linguaggio interprete e quindi posso facilmente apportare le modifiche necessarie al codice direttamente sui server di
produzione, ma mi è servito molto tempo.
Ora come è stato un linguaggio compilato.
Dovrei apportare le modifiche esternamente al codice compilato e quindi distribuire il codice
compilato sui server di produzione che richiederebbe molto tempo prezioso.
Ora, in termini di limitazioni, l'interpretazione è più lenta di ordini di grandezza che compilati o sono un paio di ragioni
per questo.
Uno sta facendo costose operazioni di accesso alla memoria.
Ad esempio questo è il codice della libreria dall'esempio di istruzioni IDE che abbiamo visto in precedenza.
Come puoi vedere ci sono diverse costose operazioni di accesso alla memoria in un linguaggio compilato.
Sarebbe stato preso per scendere in registri che potrebbero portare a un cavo che funziona molto
velocemente probabilmente anche 100 volte più velocemente.
Seconda ragione per la lentezza è che il programma deve essere reinterpretato ogni volta che viene eseguito e la limitazione è
che l'interprete viene caricato in memoria insieme al codice sorgente.
Quindi hai un programma extra che viene caricato nella memoria.
Non penso che sia un grosso problema, ma è solo qualcosa che dobbiamo sapere.
Quindi, come possiamo vedere, gli interpreti risolvono il problema dell'indipendenza della piattaforma.
Ha fatto come altre limitazioni come velocità di esecuzione lenta.
Possiamo vedere come Java sia spaventato dal problema della velocità.
Il compromesso tornato dall'Indipendenza.
Grazie.