Re: Cyrix 200+ kontraiP166

Autor: Jarek Lis (lis_at_ict.pwr.wroc.pl)
Data: Tue 11 Mar 1997 - 17:07:14 MET


Maciej Figatowski <MFigatowski_at_impaq.com.pl> wrote:
: Oj, chyba daleko odeszlismy od "Cyrix 200+ kontra iP166", ale co tam.
: Mysle, ze nie jest tak zle. Przeciez programy nie moga wykonywac sie
: lub nie w zaleznosci od dlugosci cache rozkazow - nie podejrzewam
: konstruktorow o sklonnosci samobojcze.

Jesli chodzi o cache - to tez nie przewiduje. Jakos tak sie dzieje,
ze program do RAM trzeba najpierw wpisac, zeby mogl sie wykonac, wiec
cache raczej nie sprawia problemu. Ale kolejka to problem, ktorego
rozsadny programista nie ma, bo unika takich sztuczek.

: Przeciez istnieja mechanizmy
: "przewidywania skokow" - ladowania do cache rozkazow w zaleznosci od
: przewidywanego wyniku skoku warunkowego.
Do kolejki a nie do cache.

: Pomylka przy przewidywaniu
: powoduje wyczyszczenie cache rozkazow i zaladowanie nowej zestawu spod
: wlasciwego adresu.

To w starych konstrukcjach. W nowych z chwila wczytania rozkazu skoku
warunkowego ruszaja dwa odczyty do dwoch kolejek - zeby zawsze byl
jakis rozkaz pod reka.
 
: Podejrzewam, ze przy samomodyfikujacym sie kodzie
: wykorzystywany jest ten sam mechanizm (oczywiscie oficjalnych
: informacji brak).
: A tak wogole: czy nie prosciej byloby napisac krotki program (w
: assemblerze 8086 zeby sprawdzic na wszystkich procesorach) i sprawdzic
: cala sprawe, zamiast pisac sazniste dyskusje?

O co ci chodzi - czy w ogole jest kolejka? Jest, sprawdzalem dawno temu,
inni tez sprawdzali, mozesz wierzyc nam lub dokumentacji. Program
zmieniajacy sam siebie pare bajtow dalej nie dziala w sposob przewidywalny
nawet na takim samym procesorze.

Jaroslaw Lis

+------------------------------------------------------------------------+
| lis_at_ict.pwr.wroc.pl | Institute of Engineering Cybernetics |
| tel 48-71-202636 | Technical University of Wroclaw, Poland |
| fax 48-71-203408 or 517398 | |
+------------------------------------------------------------------------+



To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:58:12 MET DST