Time Error 200 - Libreria Giobe.TPU

Scheda

RUNTIME ERROR 200 [1 di 2]

Analisi del Problema: Quando si manifesta l'errore

	Quando si tenta di mettere in esecuzione un programma compilato in ambiente Turbo Pascal (di qualunque versione) può succedere che venga segnalato l'errore Runtime Error 200.
	In pratica si tratta di un errore provocato da un superamento (trabocco) del range previsto da una determinata operazione aritmetica; di norma questa situazione è segnalata con l'errore Divide Overflow e si può manifestare quando si tenta di eseguire una divisione per 0 (nel qual caso è più propria la segnalazione d'errore Divide by 0).
	I messaggi qui citati sono alternativi e dipendono dal contesto nel quale si è verificato l'errore.

Questo fastidioso problema si manifesta in concomitanza di 2 eventi:

	la velocità elevata (maggiore o uguale a 233Mhz) del processore presente sul computer (quindi non dipende dal tipo di processore nè dal sistema operativo).
	l'uso della libreria CRT, cioè la presenza del suo nome tra quelli elencati dopo la direttiva USES.

Naturalmente entrambe le cause sono situazioni assolutamente normali: i moderni processori superano di gran lunga la frequenza massima (233Mhz) citata e difficilmente possiamo fare a meno della CRT, se vogliamo assicurare un minimo di buon gusto ai nostri programmi.

Analisi del Problema: Cosa causa l'errore

La causa dell'errore è la presenza di un difetto (non risolto!) nel codice macchina della libreria CRT.TPU, legato al modo con cui vengono realizzati i cicli di temporizzazione, cioè al modo con cui si intende consumare tempo dentro il programma assembly.

Poichè essi sono sciaguratamente realizzati con l'esecuzione di alcune istruzioni è inevitabile la loro dipendenza dalla velocità del processore.

In particolare tale errore si manifesta non appena si mette in esecuzione un eseguibile compilato in Turbo Pascal, quando la libreria CRT provvede alla sua inizializzazione, e in particolare quella della sua procedura Delay.

In questa fase:

	esegue ripetutamente un piccolo ciclo di istruzioni, con il solo scopo di consumare tempo (cioè senza far nulla) per un tempo pari a circa 55 ms.
	dopo l'esecuzione di ogni ciclo incrementa un variabile interna; al termine quest'ultima tiene conto del numero di cicli d'istruzioni effettivamente eseguiti nell'arco di 55 ms.
	al termine divide il numero ottenuto per 55, al fine di avere il numero di cicli eseguiti nell'arco di 1 ms.
	il numero ottenuto è dunque direttamente proporzionale al tempo base (1 ms) previsto dalla procedura Delay.

Questa innocua procedura, normale per le architetture dei processori contemporanei alla data della sua creazione, risulta devastante (ma non sempre...) con i moderni velocissimi processori; più veloce è il processore meno tempo ci vuole per eseguire il piccolo ciclo d'istruzioni, e quindi maggiore è il numero di cicli eseguiti nell'arco dei 55 ms (il tempo, esattamente di 54,925493 ms, è tipico del Timer di Sistema, descritto nella Scheda nella Sezione Dentro il Computer).

Premettiamo che:

	un ciclo T è il tempo corrispondente all'inverso della frequenza di un processore (per esempio 10 ns con 100MHz, 1 ns con 1GHz, 50 ns con 20MHz ...) e che mediamente ne vengono consumati alcuni per l'esecuzione di ogni istruzione...
	non conoscendo le istruzioni coinvolte nei singoli cicli d'istruzione non è possibile nemmeno prevedere il numero di cicli T consumati nella loro esecuzione.

Nelle versioni fino alla TP6:

	la variabile-contatore prevedeva la dimensione di 16 bit, pari ad un numero massimo possibile di 2¹⁶=65536 esecuzioni.
	nell'arco del tempo previsto era dunque disponibile un tempo di (55 ms/65536=) 839 ns per ogni ciclo d'istruzioni.
	supposto di fissare a 20 il numero totale di cicli T necessari per eseguire ogni ciclo d'istruzioni con un processore di prima generazione (ipotesi non basata su fatti, ma verosimile) possiamo calcolare la durata di un ciclo T: 839ns/20= circa 42 ns, pari ad una frequenza di 23,8 MHz.
	Si può concludere che che l'incremento della variabile a 16 bit provochi trabocco (errore di Overflow) già a partire da una velocità di circa soli 24 Mhz.

Nelle versioni più recenti (a partire dalla TP7):

	per cercare di porre rimedio la variabile-contatore prevede ora la dimensione di 32 bit, pari ad un numero massimo possibile di 2³²=4294967296 esecuzioni.
	nell'arco del tempo previsto è ora disponibile un tempo di (55 ms/4294967296=) 0.0128 ns per ogni ciclo d'istruzioni.
	supposto di fissare a 4 il numero totale di cicli T (i moderni processori veloci hanno architetture che ottimizzano l'esecuzione delle istruzioni, richiedendo meno cicli T) necessari per eseguire lo stesso ciclo d'istruzioni di prima, il calcolo della durata di un ciclo T è ora di 0.0128ns/4= 0.0032 ns, pari ad una frequenza di più di 312 GHz.
	è dunque impossibile che l'incremento della variabile a 32 bit provochi errore di Overflow.

Ciò non ostante anche TP7 può generare Runtime Error 200:

	non più per trabocco della variabile, ma per il fatto che essa è sottoposta alla divisione per 55 (per calcolare il tempo base di 1 ms per la *Delay) e, se la velocità del processore è troppo elevata, il risultato della divisione può essere più grande di quello massimo ospitabile* nel registro chiamato a memorizzare il quoziente, provocando la generazione di un errore.
	l'errore corretto dovrebbe essere, allora, *Divide Overflow, ma la Borland lo spaccia per errore Divide by 0* (appunto Runtime Error 200) perchè nella normale programmazione in ambiente Turbo Pascal l'unico modo per incorrere in trabocco di divisione è appunto dividere per 0.
	siccome la CPU prevede un registro a 16 bit per il quoziente della divisione di un numero a 32 bit (come la nostra variabile-contatore) il numero massimo in esso ospitabile è 2¹⁶=65536.
	poichè il numero conservato nel registro del quoziente corrisponde a 1/55 del numero massimo di cicli di istruzioni eseguibili senza errore, tale numero massimo è: 65536*55=3604480
	nell'arco del tempo previsto ogni ciclo d'istruzioni durerà dunque 55 ms/3604480= 15.26 ns.
	con la precedente ipotesi di 4 cicli T per ogni sequenza, la durata del ciclo T è dunque di (15.26ns/4=) circa 3.815 ns, pari ad una frequenza di 262 MHz.
	Si può concludere che che la divisione per 55 del registro quoziente a 16 bit provochi errore di Overflow non appena la velocità del processore supera i 262 Mhz (naturalmente nei limiti delle approssimazioni e nella veridicità delle ipotesi fatte). [segue]

	Tempo Data & Ora			RunTime Error 200
	Scheda

PASCAL »

PROCEDURE »	Caratteri \| Mouse \| Tastiera \| Tempo, Data & Ora Box \| Cornici \| Cursore \| Aree a Riga Intera \| Aree a Schermo Totale
FUNZIONI »	Caratteri \| Mouse \| Tastiera \| Tempo, Data & Ora

^Home

Pascal|Manuali|Tabelle|Schede
Tutorial Assembly|Palestra Assembler

Aggiungi Giobe®2000 ai preferiti

Motore
Ricerca

Rendi Giobe®2000 pagina di Default