🚀 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.