Dato un sistema informatico specifico, è possibile stimare il tempo di esecuzione preciso effettivo di un pezzo di codice Assembly

questo è un pezzo di codice assembly

section .text
    global _start       ;must be declared for using gcc
_start:                     ;tell linker entry point
    mov edx, len    ;message length
    mov ecx, msg    ;message to write
    mov ebx, 1      ;file descriptor (stdout)
    mov eax, 4      ;system call number (sys_write)
    int 0x80        ;call kernel
    mov eax, 1      ;system call number (sys_exit)
    int 0x80        ;call kernel

section .data

msg db  'Hello, world!',0xa ;our dear string
len equ $ - msg         ;length of our dear string

Dato un sistema informatico specifico, è possibile prevedere con precisione il tempo di esecuzione effettivo di un pezzo di codice Assembly.

Posso solo citare dal manuale di una CPU piuttosto primitiva, un processore 68020 del 1986: "Calcolare il tempo di esecuzione esatto di una sequenza di istruzioni è difficile, anche se si ha una conoscenza precisa dell'implementazione del processore". Che non abbiamo. E rispetto a un processore moderno, quella CPU era primitiva .

Non riesco a prevedere il tempo di esecuzione di quel codice, e nemmeno tu. Ma non puoi nemmeno definire cosa sia il "runtime" di un pezzo di codice, quando un processore ha enormi cache e enormi capacità fuori servizio. Un tipico processore moderno può avere 200 istruzioni "in volo", ovvero in varie fasi di esecuzione. Quindi il tempo che intercorre tra il tentativo di leggere il primo byte di istruzione e il ritiro dell'ultima istruzione può essere piuttosto lungo. Ma il ritardo effettivo rispetto a tutti gli altri lavori che il processore deve svolgere potrebbe essere (e in genere lo è) molto meno.

Naturalmente fare due chiamate al sistema operativo lo rende completamente imprevedibile. Non sai cosa faccia realmente la "scrittura su stdout", quindi non puoi prevedere l'ora.

E non puoi conoscere la velocità di clock del computer nel momento preciso in cui esegui il codice. Potrebbe essere in una modalità di risparmio energetico, il computer potrebbe avere una velocità di clock ridotta a causa del surriscaldamento, quindi anche lo stesso numero di cicli di clock può richiedere tempi diversi.

Tutto sommato: totalmente imprevedibile.

Non puoi farlo in generale, ma in un certo senso puoi farlo davvero, e ci sono stati alcuni casi storici in cui davvero dovevi farlo.

L' Atari 2600 (o Atari Video Computer System) era uno dei primi sistemi di videogiochi domestici ed è stato rilasciato per la prima volta nel 1978. A differenza dei sistemi successivi dell'epoca, Atari non poteva permettersi di fornire al dispositivo un frame buffer, nel senso che la CPU aveva per eseguire il codice su ogni scanline per determinare cosa produrre - se questo codice impiegasse 17.08 microsecondi (l'intervallo HBlank), la grafica non verrebbe impostata correttamente prima che la scanline iniziasse a disegnarli. Peggio ancora, se il programmatore voleva disegnare contenuti più complessi di quanto normalmente consentito dall'Atari, doveva misurare i tempi esatti per le istruzioni e cambiare i registri grafici mentre veniva disegnato il raggio, con un arco di 57.29 microsecondi per l'intera linea di scansione.

Tuttavia, l'Atari 2600, come molti altri sistemi basati sul 6502, aveva una caratteristica molto importante che consentiva la gestione attenta del tempo richiesta per questo scenario: la CPU, la RAM e il segnale TV funzionavano tutti con un clock basato sullo stesso master orologio. Il segnale TV scorreva su un orologio da 3,98 MHz, suddividendo i tempi sopra in un numero intero di "orologi a colori" che gestivano il segnale TV, e un ciclo di orologi CPU e RAM era esattamente tre orologi a colori, consentendo al clock della CPU di essere una misura precisa del tempo relativa all'attuale segnale TV di avanzamento. (Per ulteriori informazioni al riguardo, consulta la Guida del programmatore Stella , scritta per l' emulatore Stella Atari 2600 ).

Questo ambiente operativo, inoltre, significava che ogni istruzione CPU aveva una quantità definita di cicli che avrebbe richiesto in ogni caso, e molti 6502 sviluppatori hanno pubblicato queste informazioni nelle tabelle di riferimento. Ad esempio, considera questa voce per l' CMPistruzione (Confronta memoria con accumulatore), presa da questa tabella :

CMP  Compare Memory with Accumulator

     A - M                            N Z C I D V
                                    + + + - - -

     addressing    assembler    opc  bytes  cycles
     --------------------------------------------
     immediate     CMP #oper     C9    2     2
     zeropage      CMP oper      C5    2     3
     zeropage,X    CMP oper,X    D5    2     4
     absolute      CMP oper      CD    3     4
     absolute,X    CMP oper,X    DD    3     4*
     absolute,Y    CMP oper,Y    D9    3     4*
     (indirect,X)  CMP (oper,X)  C1    2     6
     (indirect),Y  CMP (oper),Y  D1    2     5*

*  add 1 to cycles if page boundary is crossed

Utilizzando tutte queste informazioni, Atari 2600 (e altri 6502 sviluppatori) sono stati in grado di determinare con esattezza il tempo impiegato per l'esecuzione del loro codice e di costruire routine in grado di soddisfare le esigenze di temporizzazione del segnale TV di Atari. E poiché questo tempismo era così esatto (specialmente per istruzioni che fanno perdere tempo come NOP), sono stati persino in grado di usarlo per modificare la grafica mentre venivano disegnati.

Naturalmente, l'Atari 6502 è un caso molto specifico, e tutto ciò è possibile solo perché il sistema aveva tutto quanto segue:

• Un master clock che eseguiva tutto, compresa la RAM. I sistemi moderni hanno clock indipendenti per CPU e RAM, con il clock della RAM spesso più lento e i due non necessariamente sincronizzati.
• Nessuna memorizzazione nella cache di alcun tipo: il 6502 accedeva sempre direttamente alla DRAM. I sistemi moderni hanno cache SRAM che rendono più difficile prevedere lo stato - mentre è forse ancora possibile prevedere il comportamento di un sistema con una cache, è sicuramente più difficile.
• Nessun altro programma in esecuzione contemporaneamente: il programma sulla cartuccia aveva il controllo completo del sistema. I sistemi moderni eseguono più programmi contemporaneamente utilizzando algoritmi di pianificazione non deterministici.
• Una velocità di clock abbastanza bassa da consentire ai segnali di viaggiare nel tempo nel sistema. Su un sistema moderno con velocità di clock di 4 GHz (ad esempio), sono necessari un fotone di luce 6,67 cicli di clock per percorrere la lunghezza di una scheda madre di mezzo metro: non ci si può aspettare che un processore moderno interagisca con qualcos'altro sulla scheda in un solo ciclo, poiché è necessario più di un ciclo affinché un segnale sulla scheda raggiunga anche il dispositivo.
• Una velocità di clock ben definita che cambia raramente (1,19 MHz nel caso dell'Atari): le velocità della CPU dei sistemi moderni cambiano continuamente, mentre un Atari non può farlo senza influenzare anche il segnale TV.
• Tempi di ciclo pubblicati: x86 non definisce quanto tempo impiegano le sue istruzioni.

Tutte queste cose si sono unite per creare un sistema in cui era possibile creare serie di istruzioni che richiedevano un esatto ammontare di tempo - e per questa applicazione, questo è esattamente ciò che è stato richiesto. La maggior parte dei sistemi non ha questo grado di precisione semplicemente perché non ce n'è bisogno: i calcoli vengono eseguiti quando vengono eseguiti o se è necessario un tempo esatto, è possibile eseguire una query su un orologio indipendente. Ma se la necessità è giusta (come su alcuni sistemi integrati), può ancora apparire e sarai in grado di determinare con precisione il tempo necessario per l'esecuzione del codice in questi ambienti.

E dovrei anche aggiungere l'enorme dichiarazione di non responsabilità che tutto ciò si applica solo alla costruzione di una serie di istruzioni di assemblaggio che richiederanno un esatto tempo. Se quello che vuoi fare è prendere un pezzo arbitrario di assemblaggio, anche in questi ambienti, e chiedere "Quanto tempo richiede l'esecuzione?", Non puoi categoricamente farlo - questo è il problema di Halting , che è stato dimostrato irrisolvibile.

EDIT 1: In una versione precedente di questa risposta, ho affermato che l'Atari 2600 non aveva modo di informare il processore di dove si trovasse nel segnale TV, il che lo costringeva a mantenere l'intero programma contato e sincronizzato sin dall'inizio. Come ho sottolineato nei commenti, questo è vero per alcuni sistemi come lo ZX Spectrum, ma non è vero per l'Atari 2600, poiché contiene un registro hardware che arresta la CPU fino a quando si verifica il successivo intervallo di blanking orizzontale, nonché una funzione per iniziare a piacere l'intervallo di soppressione verticale. Pertanto, il problema dei cicli di conteggio è limitato a ciascuna linea di scansione e diventa esatto solo se lo sviluppatore desidera cambiare contenuto mentre viene disegnata la linea di scansione.

Ci sono due aspetti in gioco qui

Come sottolinea @ gnasher729, se conosciamo le istruzioni esatte da eseguire, è ancora difficile stimare il tempo di esecuzione esatto a causa di cose come la cache, la previsione dei rami, il ridimensionamento, ecc.

Tuttavia, la situazione è ancora peggiore. Dato un pezzo di assemblaggio, è impossibile sapere quali istruzioni verranno eseguite o anche quante istruzioni verranno eseguite. Ciò è dovuto al teorema di Rice: se potessimo determinarlo con precisione, allora potremmo usare quell'informazione per risolvere il problema Halting, che è impossibile.

Il codice assembly può contenere salti e rami, sufficienti per rendere la traccia completa di un programma possibilmente infinita. C'è stato un lavoro su approssimazioni conservative dei tempi di esecuzione, che dà limiti superiori all'esecuzione, attraverso cose come la semantica dei costi o sistemi di tipo annotato. Non ho familiarità con nulla di specifico per il montaggio, ma non sarei sorpreso se esistesse qualcosa del genere.

La scelta del "sistema informatico" includerebbe i microcontrollori? Alcuni microcontrollori hanno tempi di esecuzione molto prevedibili, ad esempio la serie PIC a 8 bit ha quattro cicli di clock per istruzione a meno che l'istruzione non si dirami verso un indirizzo diverso, legga da flash o sia un'istruzione speciale di due parole.

Gli interrupt interromperanno inavvertitamente questo tipo di timimg, ma è possibile fare molto senza un gestore di interrupt in una configurazione "bare metal".

Utilizzando assembly e uno speciale stile di codifica è possibile scrivere codice che richiederà sempre lo stesso tempo per essere eseguito. Non è così comune ora che la maggior parte delle varianti PIC ha più timer, ma è possibile.

Nell'era dei computer a 8 bit, alcuni giochi hanno fatto qualcosa del genere. I programmatori utilizzerebbero l'esatto tempo impiegato per eseguire le istruzioni, in base al tempo impiegato e alla velocità di clock nota della CPU, per sincronizzarsi con i tempi esatti dell'hardware video e audio. A quei tempi, il display era un monitor a tubo catodico che scorreva su ogni linea di schermo a una velocità fissa e dipingeva quella fila di pixel accendendo e spegnendo il raggio catodico per attivare o disattivare i fosfori. Poiché i programmatori dovevano dire all'hardware video cosa visualizzare subito prima che il raggio raggiungesse quella parte dello schermo, e adattare il resto del codice in qualsiasi tempo rimanesse, hanno chiamato "corsa il raggio".

Non funzionerebbe assolutamente su nessun computer moderno o per codice come il tuo esempio.

Perchè no? Ecco alcune cose che rovinerebbero i tempi semplici e prevedibili:

La velocità della CPU e i recuperi di memoria sono entrambi colli di bottiglia al momento dell'esecuzione. È uno spreco di denaro eseguire una CPU più velocemente di quanto possa recuperare le istruzioni da eseguire o installare memoria in grado di fornire byte più velocemente di quanto la CPU possa accettarli. Per questo motivo, i vecchi computer funzionavano entrambi allo stesso tempo. Le moderne CPU funzionano molto più velocemente della memoria principale. Ci riescono avendo cache di istruzioni e dati. La CPU continuerà a bloccarsi se deve attendere byte che non si trovano nella cache. Le stesse istruzioni verranno quindi eseguite molto più velocemente se sono già nella cache che se non lo sono.

Inoltre, le moderne CPU hanno tubazioni lunghe. Mantengono alto il loro rendimento facendo fare in modo che un'altra parte del chip esegua i lavori preliminari sulle successive istruzioni in preparazione. Questo fallirà se la CPU non sa quale sarà la prossima istruzione, cosa che può accadere se c'è un ramo. Pertanto, le CPU tentano di prevedere i salti condizionali. (Non ne hai alcuno in questo frammento di codice, ma forse c'è stato un salto condizionato errato ad esso che ha intasato la pipeline. Inoltre, una buona scusa per collegare quella risposta leggendaria.) Allo stesso modo, i sistemi che chiamano int 80per intercettare la modalità kernel in realtà stanno utilizzando una complicata funzione della CPU, un gate di interruzione, che introduce un ritardo imprevedibile.

Se il tuo sistema operativo utilizza il multitasking preventivo, il thread che esegue questo codice potrebbe perdere la sua fetta temporale in qualsiasi momento.

La corsa del raggio funzionava anche solo perché il programma era in esecuzione sul metallo nudo e sbatteva direttamente sull'hardware. Qui stai chiamando int 80per effettuare una chiamata di sistema. Ciò passa il controllo al sistema operativo, il che non offre alcuna garanzia di tempismo. Dici quindi di eseguire l'I / O su un flusso arbitrario, che potrebbe essere stato reindirizzato a qualsiasi dispositivo. È troppo astratto per dirti quanto tempo impiega l'I / O, ma sicuramente dominerà il tempo impiegato nell'esecuzione delle istruzioni.

Se si desidera un tempismo esatto su un sistema moderno, è necessario introdurre un loop di ritardo. Devi eseguire le iterazioni più veloci alla velocità di quella più lenta, non è possibile il contrario. Uno dei motivi per cui le persone lo fanno nel mondo reale è quello di impedire la fuga di informazioni crittografiche a un utente malintenzionato in grado di determinare le richieste che richiedono più tempo di altre.

Questo è in qualche modo tangenziale, ma lo space shuttle aveva 4 computer ridondanti che dipendevano dall'essere sincronizzati accuratamente, cioè la loro corrispondenza di runtime esattamente.

Il primissimo tentativo di lancio dello space shuttle è stato cancellato quando il computer Backup Flight Software (BFS) si è rifiutato di sincronizzarsi con i quattro computer Primary Avionics Software System (PASS). Dettagli in "The Bug Heard Round the World" qui . Lettura affascinante su come il software è stato sviluppato per abbinare ciclo per ciclo e potrebbe darti un background interessante.

Penso che stiamo mescolando due diversi problemi qui. (E sì, so che questo è stato detto da altri, ma spero di poterlo esprimere più chiaramente.)

Per prima cosa dobbiamo passare dal codice sorgente alla sequenza di istruzioni che viene effettivamente eseguita (che richiede la conoscenza dei dati di input e del codice: quante volte si procede in un ciclo? Quale ramo viene preso dopo un test? ). A causa del problema di arresto, la sequenza di istruzioni può essere infinita (non terminazione) e non è sempre possibile determinarla staticamente, anche con la conoscenza dei dati di input.

Dopo aver stabilito la sequenza di istruzioni da eseguire, si desidera quindi determinare il tempo di esecuzione. Ciò può certamente essere stimato con una certa conoscenza dell'architettura del sistema. Ma il problema è che su molte macchine moderne, il tempo di esecuzione dipende fortemente dalla memorizzazione nella cache dei recuperi di memoria, il che significa che dipende tanto dai dati di input che dalle istruzioni eseguite. Dipende anche dalla corretta supposizione delle destinazioni del ramo condizionate, che di nuovo dipende dai dati. Quindi sarà solo una stima, non sarà esatto.