Autor: Maciej W. Rozycki (macro_at_macro.ds2.pg.gda.pl)
Data: Thu 27 Feb 1997 - 22:54:28 MET
On 27 Feb 1997, Piniek aka Piotr Ingling wrote:
> Jeżeli jakiś producent wypuszcza procesor, który ma być w 100% zgodny z
> intelowskim, to znaczy m.in., że każdy program napisany na Intele ma działać
> tak, jak na Intelu. A skoro nie działa, to już zmartwienie producenta procka (i
> nabywców, którzy uwierzyli reklamom). Oprogramowanie na pecety jest w końcu
> pisane na platformę intelowską, a nie cyrixową czy AMD. Jakoś nie słyszałem o
> kłopotach z 'kiepsko napisanym fragmentem' 3D Studio na oryginalnych Intelach.
Jest calkiem sporo (komercyjnych) programow, ktore nie dzialaja na PPro,
Pentium, i486, itd. Problem dotyczy zwlaszcza tych produktow, ktore
zawieraja fragmenty napisane w jezyku niskiego poziomu.
Producenci oprogramowania (sprzetu tez, ale to nie na temat) "lubia"
czasami nie stosowac sie do zalecen producentow procesorow. Np. Intel
zaleca aby nie wykorzystywac w programach bitow i rejestrow oznaczonych w
dokumentacji jako "zarezerwowane". Odradza stosowanie zaleznosci czasowych
opartych na czasie wykonania poszczegolnych rozkazow. Niewskazane jest tez
wykorzystywanie wlasciwosci specyficznych dla poszczegolnych modeli
procesora (rejestry testowe, architektura pamieci cache, itp.) w
programach ogolnego przeznaczenia. W przypadku koniecznosci wykorzystania
ktorejs z wymienionych wlasciwosci, nalezy zawsze dokladnie zidentyfikowac
producenta, rodzine i model, a czasami nawet i wersje procesora.
Niestety, producenci oprogramowania maja te zalecenia w... glebokim
powazaniu i stosuja wlasne sztuczki i triki nie baczac na mozliwe
konsekwencje. W rezultacie, program moze nie dzialac na procesorze
zachowujacym sie nieco inaczej niz ten, na ktorym testowany byl program
mimo, ze dany procesor moze byc nawet w 100% zgodny z czyms, co Intel
okresla mianem 'Architektury Intela'.
Nawiasem mowiac, przykladowe fragmenty kodu prezentowane przez Intela w
roznych dokumentach, stanowia jedne z najgorszych pod wzgledem zgodnosci z
ich wlasnymi procesorami jakie kiedykolwiek spotkalem. Np. standardowa (i
sztandarowa ;-) ) procedura identyfikacji modelu procesora, w zaleznosci
od konfiguracji sprzetu, wykazuje rozny stopien niedeterminizmu. Przy
odpowiednim stanie systemu mozna uzyskac bledne zidentyfikowanie
procesorow nowszych niz i386 w ponad 90% przypadkow. Jest tez mozliwosc
zawieszenia sie tej procedury. Czego wiec mozna wymagac od innych? ;-)
> A co do błędu dot. NT, to sam Cyrix przyznał się do błędu i wypuścił poprawione
> wersje układu.
A tak, "poprawienie" polegalo bodajze na dodaniu jednego bitu sterujacego
do ktoregos z rejestrow CCR, ktorego ustawienie, jakie przyjmuje po
podaniu sygnalu zerowania, powoduje znaczne spowolnienie wykonywania
rozkazow LOOP (w Intelu sa to jedne z najwolniejszych rozkazow skoku). Jak
ktos nie ma WinNT, to moze sobie przestawic ten bit i bedzie mial szybszy
procesor...
Jest to zapewne jeden z warunkow, jakie musi spelnic uklad scalony, aby
mozna bylo okreslic go mianem 'M$Win compatible' lub tez 'desiged for
M$Win'.
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro_at_ds2.pg.gda.pl, PGP key available +
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:56:38 MET DST