🚀 go-pugleaf

Wiktor S. napisał(a):
>>> Mam problem z przełączaniem zadań za pomocą instrukcji CALL i IRET.
>>> Przełączanie poprzez JMP działa prawidłowo, tak samo wywołanie
>>> zadania instrukcją CALL. Niestety, próba powrotu przez IRET kończy
>>> się wyjątkiem.
> 
> 
>> I prawidlowo, instrukcja iret sluzy do powrotu z procedury obslugi
>> przerwania, w twoim przypadku powinno byc chyba po prostu ret.
> 
> 
> Nie, Zgodnie z dokumentacją, jeśli przez call wywołano zadanie, iret 
> powróci do poprzedniego.

Instrukcja ret spowoduje powrot do poprzedniego TSS tylko
wtedy gdy jest to zadanie zagniezdzone, czyli jest ustawiony
bit NT rejestru eflags. W przeciwnym wypadku adres powrotu
jest pobierany ze stosu. Nalezy wiedziec ze przy JMP/CALL do
TSS adres powrotu nie jest zachowywany na stosie zadania.
Podobnie dziala iret z ta roznica ze przywraca takze stan
rejestru flag, i jest przeznaczony do powrotu z procedur
wywolanych przez tablice IDT, czyli przerwania i wyjatki.


>> To napisz chociaz konkretnie co wyswietla, jak masz podany
>> cs:ip to mozesz pokusic sie o deasemblacje kodu i sprawdzenie
>> na jakiej instrukcji sie wyklada.
> 
> 
> Wyjątek 0D na instrukcji iret.

W twoim przypadku nie wiadomo co sie znajduje na szczycie
stosu wiec powrot nastepuje w 'kosmos', stad wyjatek #GP.
W tym wypadku proponuje Ci zamiast iret, call do dowolnie
wybranego TSS, tak jak to rozwiazales z JMP.

>> Po co robic takie obejscia w stylu db 9ah...,
> 
> Bo tasm (w przeciwieństwie do nasma) jest porąbany i wszelkie kombinacje 
> z "call 64:0", call [64:0], call far ..., call dword ptr ...
> itd. kończą się albo komunikatem "illegal immediate", albo "near call to 
> different cs", albo inną instrukcją, niż o którą chodzi.
> Niestety, jestem tu skazany na tasma.

Ja juz dawno porzucilem tasma, glownie dlatego, ze praktycznie
nie jest tam mozliwe legalne mieszanie kodu 16 i 32 bitowego.
Poczatkowo na rzecz nasm'a, potem byl fasm, a obecnie at&t.

>> a do testowania bardziej sie chyba nada bochs,
>> http://bochs.sourceforge.net/
> 
> Dlaczego bardziej? Bochs jest dużo wolniejszy, bo emuluje procka 
> programowo.

Przy takim przykladzie raczej nie zauwazysz wplywu emulacji
na szybkosc dzialania twojego programu. A na dodatek
masz tam wbudowany debugger, ktory pozwoli Ci obejrzec
stan procesora w dowolnie wybranym momencie.
No i w przeciwinstwie do M$ VirtualPC jest darmowy.


-- 
Pozdrawiam
Lopez