🚀 go-pugleaf

On 2010-04-16 00:23, Andrzej Gra�y�ski wrote:
>
> Jaki proponujecie spos�b sprawdzenia, czy progam chodzi na Pentium czy
> na starszym badziewiu?
>
> Konkretnie problem jest taki: jest program DOSowy, ma ju� ze 25 lat,
> jest troch� rozwijany. Niekt�rzy ludzie maj� jeszcze 486, s� nawet dwa
> 386DX40. Ja chcia�bym u�y� instrukcji RDTSC, oczywi�cie pod warunkiem,
> �e procesor takow� posiada (konkretnie chodzi o reimplementacj� funkcji
> Delay() w Turbo Pascalu - gdy nie b�dzie RDTSC, wykonany zostanie
> klasyczny wariant z p�tl� programow� przerobion� na 32 bity, �eby
> unikn�� b��du 200, znana sprawa). Je�li b�die mo�na u�y� RDTSC, to
> b�dzie lepiej, bo Delay() b�zie lizone w czasie rzeczywistym, a nie w
> czasie, kt�ry procesor po�wi�ci zadaniu.

Najpierw sprawdzamy, czy procesor ma CPUID (bit w EFLAGS). Je�li ma -
dalej jest prosto. Je�li nie ma - mo�e to by� najwy�ej 486 i TSC nie ma
na pewno.
Istnieje ca�a masa test�w umo�liwaj�cych stwierdzenie typu <= 486 na
podstawie zachowa� procesora przy wykonaniu instrukcji.
Niezale�nie od TSC istnieje jeszcze timer systemowy i zmienna timera
(zlicza interwa�y ok. 55 ms) w pami�ci, dost�pna dla apikacji DOSowych.

Bernard pisze:
> On 2010-04-16 00:23, Andrzej Gra�y�ski wrote:
>>
>> Jaki proponujecie spos�b sprawdzenia, czy progam chodzi na Pentium czy
>> na starszym badziewiu?
>>

[CIACH]

>
> Najpierw sprawdzamy, czy procesor ma CPUID (bit w EFLAGS). Je�li ma -
> dalej jest prosto. Je�li nie ma - mo�e to by� najwy�ej 486 i TSC nie ma
> na pewno.

Dzi�kuj�, ten test ju� znam.



> Istnieje ca�a masa test�w umo�liwaj�cych stwierdzenie typu <= 486 na
> podstawie zachowa� procesora przy wykonaniu instrukcji.

To te� jest powszechnie znane, cho� teraz nie jest mi potrzebne.


> Niezale�nie od TSC istnieje jeszcze timer systemowy i zmienna timera
> (zlicza interwa�y ok. 55 ms) w pami�ci, dost�pna dla apikacji DOSowych.

Oczywi�cie, i gdy nie by�o RDTSC to by� jednyn ysposob odmierzania
czasu, cho� ma�o dok�adny. W Turbo Pascalu zaimplementowano programowo
dok�adniejszy zegarek: kr�ci si� pewn� wzorcow� p�tl�, zlicza jej obroty
mi�zy kolejnymi tylkni�ciami zegara pod adresem BIOS:$6C, a potem
przelicza jedn� milisekund� na liczb� obrot� tej p�tli. To by�o dobre
jeszcze dla 386, ale teraz jest do�� zawodne, bo:

1. W systemie wieloprogramowym p�tla kr�ci si� tylko wtedy, gdy zadanie
ma przydzielony czas procesora

2. W nowszych procesorach czas jednego obrotu p�tli mo�e by�
zr�nicowany, ze wzgl�du na mechanizmy optymalizacyjne (cacheowanie,
potok rozkaz�w).

W efekcie Delay(1000) nie zawsze daje jedn� sekund� oczekiwania. Te
mankamenty znikn�, je�li zamiast programowej p�tli u�yjemy RDTSC:


1. czekamy, a� zmieni si� warto�� zegara BIOS:$6C

2. Odczytujemy RDTSC i zapisujemy do TSCSTART

3. czekamy, a� zmieni si� warto�� zegara BIOS:$6C

4. Odczytujemy RDTSC i zapisujemy do TSCSEND

5. Obliczamy liczb� tykni�� TSC na milisekund�:

   TSCPERMSEC = (TSCEND-TSCSTART)*(1193180/65536/1000)

i odt�d mo�emy odmierza� interwa�y w czasie rzeczywistym.



Delay(MSec:Word):



TSCCOUNT := MSec * TSCPERMSEC;

TSC <- RDTSC
TSCEND <- TSC + TSCCOUNT-1

repeat
   TSC <- RDTSC
until TSC >= TSCEND;

Andrzej Gra¿yñski <grazynsk@petex.com.pl> wrote:

> [...]

Pytanie takie: te programy dzia³aj± pod DOS-em?

w.

Wojciech Mu�a pisze:
> Andrzej Gra�y�ski <grazynsk@petex.com.pl> wrote:
>
>> [...]
>
> Pytanie takie: te programy dzia�aj� pod DOS-em?
>
> w.
Niekt�re pod DOSem+DPMI inne w oknie DOSowym Windows, niekt�re w DOSemu.
1 760 000 linii w Pascalu nie op�aca si� przerabia� na co� nowszego.
Chodzi bez zarzutu, bez trudu daje si� rozbudowywa�.

Andrzej Gra¿yñski <grazynsk@petex.com.pl> wrote:

> > Pytanie takie: te programy dzia³aj± pod DOS-em?
> 
> Niektóre pod DOSem+DPMI inne w oknie DOSowym Windows, niektóre w DOSemu. 
> 1 760 000 linii w Pascalu nie op³aca siê przerabiaæ na co¶ nowszego. 
> Chodzi bez zarzutu, bez trudu daje siê rozbudowywaæ.

Nie dlatego pyta³em. Gdyby dzia³a³y tylko pod DOS-em, to
mo¿naby spróbowaæ przeprogramowaæ zegarek RTC, ¿eby tyka³
szybciej i tylko zczytywaæ jaki¶ globalny licznik.

w.

Andrzej Grażyński wrote:

> W efekcie Delay(1000) nie zawsze daje jedną sekundę oczekiwania. Te
> mankamenty znikną, jeśli zamiast programowej pętli użyjemy RDTSC:

za to pojawia sie inne problemy.

> 1. czekamy, aż zmieni się wartość zegara BIOS:$6C
>
> 2. Odczytujemy RDTSC i zapisujemy do TSCSTART
>
> 3. czekamy, aż zmieni się wartość zegara BIOS:$6C
>
> 4. Odczytujemy RDTSC i zapisujemy do TSCSEND
>
> 5. Obliczamy liczbę tyknięć TSC na milisekundę:
>
>    TSCPERMSEC = (TSCEND-TSCSTART)*(1193180/65536/1000)
>
> i odtąd możemy odmierzać interwały w czasie rzeczywistym.

Badz ostrozny. W niektorych procesorach RDTSC liczy cykle w rozny sposob. W
przypadku procesorow obslugujacych SpeedStep (Intel) albo Cool'n'Quiet (AMD)
rdtsc moze zliczac cykle zaleznie od tego, z jaka predkoscia pracuje CPU w
danej chwili. Twoja petla kontrolna zmierzy sie na przyklad przy 800MHz, a
pozniej np. CPU przelaczy sie na 1800MHz.

Jezeli to mozliwe, uzyj timera z lokalnego APIC. Jest troche mniej dokladny
(100MHz, na przyklad) ale za to niezalezny od predkosci taktowania CPU.

--
Michal Schulz

W dniu 16.04.2010 00:23, Andrzej Gra�y�ski pisze:
>
> Jaki proponujecie spos�b sprawdzenia, czy progam chodzi na Pentium czy
> na starszym badziewiu?
>
> Konkretnie problem jest taki: jest program DOSowy, ma ju� ze 25 lat,
> jest troch� rozwijany. Niekt�rzy ludzie maj� jeszcze 486, s� nawet dwa
> 386DX40. Ja chcia�bym u�y� instrukcji RDTSC, oczywi�cie pod warunkiem,
> �e procesor takow� posiada (konkretnie chodzi o reimplementacj�  funkcji
> Delay() w Turbo Pascalu - gdy nie b�dzie RDTSC, wykonany zostanie
> klasyczny wariant z p�tl� programow� przerobion� na 32 bity, �eby
> unikn�� b��du 200, znana sprawa). Je�li b�die mo�na u�y� RDTSC, to
> b�dzie lepiej, bo Delay() b�zie lizone w czasie rzeczywistym, a nie w
> czasie, kt�ry procesor po�wi�ci zadaniu.

http://rudy.mif.pg.gda.pl/~bogdro/dos/cpu_tut.htm

--
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.JabberPL.org www.TorProject.org Soft (EN): miniurl.pl/bogdro-soft

> Jezeli to mozliwe, uzyj timera z lokalnego APIC. Jest troche mniej dokladny
> (100MHz, na przyklad) ale za to niezalezny od predkosci taktowania CPU.
>

Ba, ale jak to zrobić, żeby aplikacja chodziła w oknie DOSowym WIndows?

>
> http://rudy.mif.pg.gda.pl/~bogdro/dos/cpu_tut.htm
>

Dzi�ki.

U�ytkownik "Andrzej Gra�y�ski" napisa�:

> �eby unikn�� b��du 200

Czy remedium nie jest kompilacja we Free Pascalu? Nie sprawdza�em. Czyta�em
co� na ten temat.

Remek

Remek pisze:
> U�ytkownik "Andrzej Gra�y�ski" napisa�:
>
>> �eby unikn�� b��du 200
>
> Czy remedium nie jest kompilacja we Free Pascalu? Nie sprawdza�em.
> Czyta�em co� na ten temat.
>
> Remek

A zagwarantujesz mi, �e wszystko co do ka�dego szczeg�u chodzi tak
samo? Oto prosty przyk�ad r�nicy:

var
   W, M: Word;
   L: Longint;

...

W = 5;
M = 7;

L := W-M;

if L < 0 then
begin
   { jeste�my we FreePascalu }
end
else
begin
   { jeste�my w Turbo Pascalu }
end;


Takich kwiatk�w jest mn�stwo. Ryzyko zbyt du�e. Pomijaj�c ju� fakt, �e
trzeba doprowadzi� kod do mo�liwo�ci skompilowania w FP.

A w�tek obiektowy - uzale�nienie od konkretnego layoutu obiektu w BP7?
Pewnie w FP jest zupe�nie inny. Wi�c nawet jak si� teoretycznie
skompiluje...

Remek pisze:
> U�ytkownik "Andrzej Gra�y�ski" napisa�:
>
>> �eby unikn�� b��du 200
>
> Czy remedium nie jest kompilacja we Free Pascalu? Nie sprawdza�em.
> Czyta�em co� na ten temat.
>
> Remek
A propos b��du 200 - to dzi� nie jest ju� problem. kto chce grzeba� w
�r�d�ach CRT, sam sobie poradzi w ci�gu p� godziny. Kto nie chce, ma
gotowe narz�dzie z Borlanda patchuj�ce EXEki. Mnie chodzi�o o co�
zupe�nie innego - o jako tak� adekwatno�� odmierzanego czasu.