Newsgroup: it.comp.lang.pascal
Titolo: Libreria CRT corretta

Ho appena terminato la correzione del bug nella libreria CRT del
Borland/Turbo Pascal 7.
Tale libreria e' ora disponibile nella mia homepage
(
www.tiscalinet.it/drfalken
), sezione "Patch, Tips & Tricks".
Sono allegati anche un piccolo file di esempio ed un file batch per
modificare il file TURBO.TPL (o TPP.TPL per la modalita' protetta)
contenente la libreria CRT.
La libreria e' in fase di testing, quindi si accettano commenti,
correzioni....qualsiasi cosa la possa migliorare.
Il codice della procedura Delay nella libreria CRT (corretta) e' ora:
procedure Delay(MS: Word);
var
   t_end: longint;
begin
     t_end := MemL[Seg0040:$6c]+longint(ms) div 55;
     { 0:46Ch contiene un valore di 32 bit }
     while MemL[Seg0040:$6c]<t_end do;
end;
Naturalmente rimane il problema della mezzanotte (facilmente eliminabile) e
della risoluzione (attualmente 55ms): si accettano routine
alternative in grado di soddisfare tali requisiti. (la migliore sara'
inserita, al posto
di quella che ho proposto, nel prossimo aggiornamento)
Ciao!
Simone.
_____________________________________________
"....c'e' vita nell'universo ?"
"Giusto un po' il sabato sera...."
            C.Guzzanti
e-mail:  
drfa...@libero.it
 
drfa...@tiscalinet.it
 
drfa...@tin.it
web:     
http://www.tiscalinet.it/drfalken
 
http://free.prohosting.com/~drfalken
ICQ#:  19598133
_____________________________________________

Un suggerimento : non sarebbe meglio tradurla in assembly ?
--------------------------------------------------------
* Andrea Laforgia        (
andrea_...@bigfoot.com
) *
--------------------------------------------------------




ciao Simone,
scrivo per la prima volta sugli Ng in generale e ho voluto cominciare, e forse
finire, con quello che mi Š sembrato pi— serio e leggo volentieri di tanto in
tanto. Ho letto spesso i tuoi interventi dai quali ho capito che sei uno dei
pi— validi sostenitori del Pascal. Leggendo il messaggio riguardante la tua
stesura della tpu CRT, ho voluto intervenire sperando che le routines di delay
che ho fatto quando mi sono imbattuto su quel bell'errore di runtime possano
aiutarti a migliorare la funzione di ritardo. Le routines sono in assembler e
si compongono di due sezioni distinte: la prima routines serve ad
inizializzare la variabile di ritardo e deve essere inserita
nell'inizializzazione della TPU. la seconda Š la vera e propria procedura di
delay. bene, ho finito. spero potranno esserti utili. se dovessi avere dei
problemi postami in E-mail o nell'NG. Ciao.
Giuseppe Di Grande.
P.S.: i problemi della mezzanotte e del multiplo di 55 millisecondi non
dovrebbero essere pi— un problema, almeno spero!
**
unit crt;
interface
procedure delay(mls:word);
implementation
var
ritardo : longint;
function systime : longint; assembler;
asm
in al,21h
push ax
mov al,0feh
out 21h,al
push es
mov ax,0040h
mov es,ax
mov di,6ch
xor ax,ax
xor dx,dx
mov bl,es:[di]
@p01:
cmp bl,es:[di]
je @p01
mov bl,es:[di]
@p02:
add ax,1
adc dx,0
cmp dx,0ffffh
je @p03
cmp bl,es:[di]
je @p02
@p03:
pop es
pop ax
out 21h,al
end;
PROCEDURE delay(MLS : WORD); ASSEMBLER;
asm
push es
mov ax,0040h
mov es,ax
xor di,di
mov bl,es:[di]
mov cx,mls
@p01:
mov ax,word ptr[ritardo]
mov dx,word ptr [ritardo +2]
@p2:
sub ax,1
sbb dx,0
cmp dx,0ffffh
je @p03
cmp bl,es:[di]
je @p02
@03:
loop @p01
pop es
end;
begin
ritardo := systime div 55;
end.
**
 

Scusa Simone,
gli errori vengono individuati sempre dopo aver messo in giro i programmi, i
listati, o qualsiasi altra cosa, ma sempre dopo! L'hai notato?
be', scusami, ti rimando le routines. Ho modificato qualcosina nella funzione
SYSTIME, okay?
ora dovrebbe andare. prima la word bassa, quella in AX,
che veniva fuori dalla funzione veniva sovrascritta da una maledetta
dimenticanza di richiamo dello stack. ancora ciao.
Giuseppe Di Grande
m...@viesse.it
www.viesse.it/mad
**
unit crt;
interface
procedure delay(mls:word);
implementation
var
ritardo : longint;



@p03:
mov bx,ax
pop es
pop ax
out 21h,al
mov ax,bx



Allora, la procedura DELAY dev'essere scritta in modo da poter "generare" un
ritardo in modo da non dipendere dal processore.
Ogni istruzione ha un proprio tempo di esecuzione e, sotto alcune ipotesi,
puo' essere eseguito in parallelo con altre istruzioni, quindi il ciclo
P01-P03 della SYSTIME non e' identico al ciclo P01-P03 della DELAY.
Le soluzioni sono due:
    1. i cicli delle due procedure vanno resi identici (le istruzioni devono
essere necessariamente le stesse)
    2. la durata dei due cicli dev'essere identica (anche se le istruzioni
non sono le stesse)
Innanzitutto, prima del ciclo (indipendentemente dalla soluzione utilizzata)
potrebbe essere necessario "svuotare" le pipeline del processore, eseguendo
un paio di istruzioni di tipo NP ("Not Pairable"="non accoppiabile" con
altre istruzioni, es: NOT AX; NOT AX).
A questo punto, se i cicli eseguono le stesse istruzioni allora la loro
durata sara' identica.
Invece, se i cicli vengono implementati con istruzioni diverse (tipo ADD+ADC
per SYSTIME e SUB+SBB per DELAY), allora devono essere scelte in modo da
comportarsi (in termini di tempo d'esecuzione e pipeline) nello stesso modo.
Comunque, per la cronaca:
[PV] = solo Pipeline V
[PU] = solo Pipeline U
[UV] = U o V indifferentemente
[NP] = non accoppiabile
SYSTIME:
    ...
    ...
    @p02:
[UV]    add ax,1
[PU]    adc dx,0
[UV]    cmp dx,0ffffh
[PV]    je @p03
    ...
    ...
DELAY:
    ...
    ...
    @p2:
[UV]    sub ax,1
[PU]    sbb dx,0
[UV]    cmp dx,0ffffh
[PV]    je @p03
    ...
    ...
Ad occhio e croce dovrebbero comportarsi allo stesso modo, comunque per
correttezza il ciclo andrebbe analizzato anche per le iterazioni successive.
(per altre info, ti consiglio di dare un'occhiata ad "AP-526 APPLICATION
NOTE" di Intel, in formato pdf....se ti serve te lo posso inviare, occupa
330k zippato/410k pdf)
Comunque, secondo me, il sistema migliore e piu' semplice sarebbe il primo,
cioe' rendere identici i cicli interni.
Nel prossimo post cerchero' di pubblicare le tue routine modificate.
Ciao!
Simone.
