[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

pl.comp.programming

64b OS - IA-32e i stronicowanie

Karol \"Zal\" Zalewski

6/12/2007 8:03:00 PM

Witam serdecznie!

Na wstÄ?pie chciaÅ?bym zaznaczyÄ?, iż pytanie (jest to cel przewodni tej
wiadomoÅ?ci - patrz czwarty akapit) moje kierujÄ? do osób, które majÄ? już
doÅ?wiadczenie w pisaniu systemów operacyjnych w oparciu o architekturÄ?
IA-32e.

ZacznÄ? zatem od poczÄ?tku. JakiÅ? czas temu rozpoczÄ?Å?em z grupÄ? kolegów ze
studiów prace nad rozwojem prostego 16b systemu operacyjnego - w ramach
zajÄ?Ä? z "Oprogramowania systemowego". System ten pisany w zupeÅ?noÅ?ci w
Asemblerze, przy wykorzystaniu asemblera TASM, a uruchamiany z poziomu
DOS (jako plik .exe) nie byÅ? trudny do modyfikacji. PosiadaÅ? już
segmentacjÄ?, zarzÄ?dzanie przerwaniami, przejÅ?cie do trybu chronionego
itp. itd. Wszystko oprócz stronicowania. Niemniej jednak przeksztaÅ?cenie
caÅ?oÅ?ci tak, aby pracowaÅ?a w 32b nie stanowiÅ?o wielkiego problemu.

KÅ?opoty rozpoczÄ?Å?y siÄ? tuż po tym, jak postanowiliÅ?my kontynuowaÄ?
projekt w celu uzyskania prostego systemu 64b. Archaiczny asembler byÅ? i
nadal jest tutaj pewnym utrudnieniem, ale nie to jest najważniejsze.
PosÅ?ugujÄ?c siÄ? dokumentacjÄ? Intela (m.in. IA-32 Intel Architecture
Software Developer's Manual Volume 3A - sekcja 9.8.5) doszliÅ?my już do
momentu w którym to posiadamy utworzone struktury wymagane przez
stronicowanie w trybie 64b i jesteÅ?my w trakcie procedury, która
umożliwi przejÅ?cie do trybu kompatybilnoÅ?ci z kodem 32b. JesteÅ?my
Å?wiadomi tego, iż użyta w trybie 32b segmentacja nie jest już
obsÅ?ugiwana - na rzecz stronicowania. W każdym bÄ?dź razie każda próba
implementacji piÄ?cioetapowego (wspomniana wyżej sekcja 9.8.5) procesu
przejÅ?cia do trybu kompatybilnoÅ?ci koÅ?czy siÄ? restartem tuż po wpisaniu
do CR0.PG jedynki (aktywacja stronicowania).

Po tym dÅ?ugim opisie mam już tylko krótkie pytanie. Czy możliwym jest,
aby problemem byÅ?o przejÅ?cie z segmentacji w trybie 32b do stronicowania
w trybie kompatybilnoÅ?ci? Czy wymagane jest zaimplementowanie
stronicowania w trybie 32b tylko po to, aby móc nastÄ?pnie przejÅ?Ä? do
stronicowania w trybie kompatybilnoÅ?ci?

BÄ?dÄ? wdziÄ?czny za wszelkiego rodzaju sugestie. Jestem Å?wiadom tego, iż
to co napisaÅ?em może byÄ? dla wielu zbyt dÅ?ugie, nużÄ?ce i niezrozumiaÅ?e.
Niemniej jednak nadal liczÄ? na to, iż ktoÅ? (korzystajÄ?c ze swojego
doÅ?wiadczenia) bÄ?dzie w stanie mi udzieliÄ? odpowiedzi. Nawet jeżeli
odpowiedź brzmiaÅ?aby mniej/wiÄ?cej w ten sposób: "nie wiem, o co ci
chodzi, ale zabraliÅ?cie siÄ? od tego od zÅ?ej strony" :D

Pozdrawiam,
Karol "Zal" Zalewski

PS. PrzeglÄ?daÅ?em parÄ? grup dyskusyjnych i mam nadziejÄ?, iż *trafiÅ?em* w
tÄ? odpowiedniÄ?. Z góry przepraszam, jeżeli nie trafiÅ?em. Mam również
nadziejÄ?, iż kodowaniem i dÅ?ugoÅ?ciÄ? linii (70) nikogo nie porażÄ? ;]
Jeszcze nie przywykÅ?em do zasad, którymi rzÄ?dzi siÄ? Usenet.
8 Answers

Lopez

6/13/2007 9:24:00 AM

0

Karol "Zal" Zalewski napisa3(a):
> Witam serdecznie!

Witam.

> K3opoty rozpocze3y sie tu? po tym, jak postanowili?my kontynuowaa
> projekt w celu uzyskania prostego systemu 64b. Archaiczny asembler by3 i
> nadal jest tutaj pewnym utrudnieniem, ale nie to jest najwa?niejsze.
> Pos3uguj?c sie dokumentacj? Intela (m.in. IA-32 Intel Architecture
> Software Developer's Manual Volume 3A - sekcja 9.8.5) doszli?my ju? do
> momentu w którym to posiadamy utworzone struktury wymagane przez
> stronicowanie w trybie 64b i jeste?my w trakcie procedury, która
> umo?liwi przej?cie do trybu kompatybilno?ci z kodem 32b. Jeste?my
> ?wiadomi tego, i? u?yta w trybie 32b segmentacja nie jest ju?
> obs3ugiwana - na rzecz stronicowania. W ka?dym b?d? razie ka?da próba
> implementacji piecioetapowego (wspomniana wy?ej sekcja 9.8.5) procesu
> przej?cia do trybu kompatybilno?ci konczy sie restartem tu? po wpisaniu
> do CR0.PG jedynki (aktywacja stronicowania).

Rozumiem, ?e uzywacie emulatora, i sprawdzacie koncowy stan rejestrow
w logach. Zaimplementujcie dokladnie obsluge wyjatkow, to sie nie
bedzie restartowal, DF i NMI nalezy potraktowac szczegolnie i dac
im osobny TSS. Kilka procedur debugujacych tez bedzie przydatne,
jakies pulapki, itp.dojdziecie
do punktu, w ktorym dodanie jakiejkolwiek opcji moze sie okazac
tak czasochlo

> Po tym d3ugim opisie mam ju? tylko krótkie pytanie. Czy mo?liwym jest,
> aby problemem by3o przej?cie z segmentacji w trybie 32b do stronicowania
> w trybie kompatybilno?ci? Czy wymagane jest zaimplementowanie
> stronicowania w trybie 32b tylko po to, aby móc nastepnie przej?a do
> stronicowania w trybie kompatybilno?ci?

OIDP to nie jest konieczne,
mozesz wskoczyc do dowolnego trybu pracy procesora.
Pod warunkiem oczywiscie odpowiedniego przygotowania srodowiska
docelowego.
Swoja droga, to predzej czy pozniej i tak Cie czeka implementacja
stronicowania, tak wiec proponuje dobrze opanowac to na poziomie
32-bitow zanim zaczniesz mieszac na dluzszych trybach.

> odpowied? brzmia3aby mniej/wiecej w ten sposób: "nie wiem, o co ci
> chodzi, ale zabrali?cie sie od tego od z3ej strony" :D

Poniekad, troche jest w tym prawdy. W asemblerze wasz projekt
szybko sie skomplikuje. 90% kodu mozecie napisac w C,
bedzie zdecydowanie szybciej i wygodniej.
Ale to juz tylko moja prywatna opinia.

--
Pozdrawiam
Lopez

Lopez

6/13/2007 9:29:00 AM

0

Lopez napisa3(a):
> Karol "Zal" Zalewski napisa3(a):
>> Witam serdecznie!
>

> jakies pulapki, itp.dojdziecie
> do punktu, w ktorym dodanie jakiejkolwiek opcji moze sie okazac
> tak czasochlo
>

Nie zwazajcie na to zdanie, zaczalem mysl, ale ostatecznie
postanowilem ja usunac, nie mam w ogole pojecia jak to
przedostalo do tresci postu.

--
Pozdrawiam
Lopez

Karol \"Zal\" Zalewski

6/13/2007 11:48:00 AM

0

Lopez napisaÅ?:

> Rozumiem, że uzywacie emulatora, i sprawdzacie koncowy stan rejestrow
> w logach. Zaimplementujcie dokladnie obsluge wyjatkow, to sie nie
> bedzie restartowal, DF i NMI nalezy potraktowac szczegolnie i dac
> im osobny TSS. Kilka procedur debugujacych tez bedzie przydatne,
> jakies pulapki, itp.dojdziecie
> do punktu, w ktorym dodanie jakiejkolwiek opcji moze sie okazac
> tak czasochlo

Przyznam szczerze, iż z emulatorów korzystaliÅ?my w momencie tworzenia
32b wersji. Obecnie dziaÅ?amy zupeÅ?nie po omacku. ObsÅ?uga wyjÄ?tków też
pozostaje niezaimplementowana. BylibyÅ?my wdziÄ?czni za wskazówki
dotyczÄ?ce tego w jaki sposób zabraÄ? siÄ? za debugowanie kodu 64b.

> OIDP to nie jest konieczne,
> mozesz wskoczyc do dowolnego trybu pracy procesora.
> Pod warunkiem oczywiscie odpowiedniego przygotowania srodowiska
> docelowego.
> Swoja droga, to predzej czy pozniej i tak Cie czeka implementacja
> stronicowania, tak wiec proponuje dobrze opanowac to na poziomie
> 32-bitow zanim zaczniesz mieszac na dluzszych trybach.

DziÄ?kujÄ? bardzo za tÄ? wskazówkÄ?. Tak też wÅ?aÅ?nie zrobimy - spróbujemy
zaimplementowaÄ? stronicowanie w 32b trybie i dopiero wtedy zabierzemy
siÄ? za 64b.

>
> Poniekad, troche jest w tym prawdy. W asemblerze wasz projekt
> szybko sie skomplikuje. 90% kodu mozecie napisac w C,
> bedzie zdecydowanie szybciej i wygodniej.
> Ale to juz tylko moja prywatna opinia.
>

W zupeÅ?noÅ?ci siÄ? z TwojÄ? opiniÄ? zgadzam. Już od jakiegoÅ? czasu
myÅ?laÅ?em nad tym, aby przepisaÄ? caÅ?oÅ?Ä? na nowo w C z wstawkami w
Asemblerze. OczywiÅ?cie na tym polu też nie posiadamy doÅ?wiadczenia,
ale dostÄ?pne w Internecie pomoce z pewnoÅ?ciÄ? okazaÅ?yby siÄ? tutaj
przydatne. Niemniej jednak prowadzÄ?cy, który zleciÅ? nam realizacjÄ?
projektu prosiÅ?, aby byÅ? on rozwiniÄ?ciem już istniejÄ?cego przy
wykorzystaniu czystego kodu asemblerowego.

Pozdrawiam,
Karol "Zal" Zalewski

PS. Jeszcze raz dziÄ?kujÄ? za odpowiedź.

Lopez

6/13/2007 12:20:00 PM

0

Karol "Zal" Zalewski napisa3(a):
> Lopez napisa3:
>
>> Rozumiem, ?e uzywacie emulatora, i sprawdzacie koncowy stan rejestrow
>> w logach. Zaimplementujcie dokladnie obsluge wyjatkow, to sie nie
>> bedzie restartowal, DF i NMI nalezy potraktowac szczegolnie i dac
>> im osobny TSS. Kilka procedur debugujacych tez bedzie przydatne,
>> jakies pulapki, itp.dojdziecie
>> do punktu, w ktorym dodanie jakiejkolwiek opcji moze sie okazac
>> tak czasochlo
>
> Przyznam szczerze, i? z emulatorów korzystali?my w momencie tworzenia
> 32b wersji. Obecnie dzia3amy zupe3nie po omacku. Obs3uga wyj?tków te?
> pozostaje niezaimplementowana. Byliby?my wdzieczni za wskazówki
> dotycz?ce tego w jaki sposób zabraa sie za debugowanie kodu 64b.

Bochs, ale musisz kompilowac recznie, gdyz ani wersje binarne
dostepne na stronie http://bochs.source...
ani te dystrybucyjne nie posiadaja obslugi x86-64.
Posiada tez wbudowany debugger a'la gdb.
Mysle, ze to tez sie przyda
http://developer.amd.com/dev...
szczegolnie sekcja manuals.

--
Pozdrawiam
Lopez

Bernard

6/13/2007 7:06:00 PM

0

Karol "Zal" Zalewski wrote:
> Zaczne zatem od pocz?tku. Jaki? czas temu rozpocz?3em z grup? kolegów ze
> studiów prace nad rozwojem prostego 16b systemu operacyjnego - w ramach
> zajea z "Oprogramowania systemowego". System ten pisany w zupe3no?ci w
> Asemblerze, przy wykorzystaniu asemblera TASM, a uruchamiany z poziomu
> DOS (jako plik .exe) nie by3 trudny do modyfikacji. Posiada3 ju?
> segmentacje, zarz?dzanie przerwaniami, przej?cie do trybu chronionego
> itp. itd. Wszystko oprócz stronicowania. Niemniej jednak przekszta3cenie
> ca3o?ci tak, aby pracowa3a w 32b nie stanowi3o wielkiego problemu.
>
> K3opoty rozpocze3y sie tu? po tym, jak postanowili?my kontynuowaa
> projekt w celu uzyskania prostego systemu 64b. Archaiczny asembler by3 i
> nadal jest tutaj pewnym utrudnieniem, ale nie to jest najwa?niejsze.

Czemu nie u?ywacie FASMa lub najnowszego NASMa?

> Pos3uguj?c sie dokumentacj? Intela (m.in. IA-32 Intel Architecture
> Software Developer's Manual Volume 3A - sekcja 9.8.5) doszli?my ju? do
> momentu w którym to posiadamy utworzone struktury wymagane przez
> stronicowanie w trybie 64b i jeste?my w trakcie procedury, która
> umo?liwi przej?cie do trybu kompatybilno?ci z kodem 32b. Jeste?my
> ?wiadomi tego, i? u?yta w trybie 32b segmentacja nie jest ju?
> obs3ugiwana - na rzecz stronicowania. W ka?dym b?d? razie ka?da próba

?e co? Segmentacja jest zredukowana do minimum tylko w trybie
64-bitowym, w trybie zgodno?ci dzia3a jak dzia3a3a.

> implementacji piecioetapowego (wspomniana wy?ej sekcja 9.8.5) procesu
> przej?cia do trybu kompatybilno?ci konczy sie restartem tu? po wpisaniu
> do CR0.PG jedynki (aktywacja stronicowania).

No to co? namieszali?cie zdrowo.

> Po tym d3ugim opisie mam ju? tylko krótkie pytanie. Czy mo?liwym jest,

Mo?e i d3ugim, tylko ?e kompletnie nic nie napisa3e?...

> aby problemem by3o przej?cie z segmentacji w trybie 32b do stronicowania
> w trybie kompatybilno?ci? Czy wymagane jest zaimplementowanie
> stronicowania w trybie 32b tylko po to, aby móc nastepnie przej?a do
> stronicowania w trybie kompatybilno?ci?

Nie ma "przej?cia z segmentacji do stronicowania". Jest segmentacja i
jest stronicowanie, praktycznie niezale?ne od siebie.

> Bede wdzieczny za wszelkiego rodzaju sugestie. Jestem ?wiadom tego, i?
> to co napisa3em mo?e bya dla wielu zbyt d3ugie, nu??ce i niezrozumia3e.
> Niemniej jednak nadal licze na to, i? kto? (korzystaj?c ze swojego
> do?wiadczenia) bedzie w stanie mi udzielia odpowiedzi. Nawet je?eli
> odpowied? brzmia3aby mniej/wiecej w ten sposób: "nie wiem, o co ci
> chodzi, ale zabrali?cie sie od tego od z3ej strony" :D

Ja to robie tak (celem u mnie by3o napisanie najkrótszego programu typu
..COM, który prze3?cza w tryb 64-bitowy i z powrotem do rzeczywistego,
wiec to nie ca3kiem to, o co Ci chodzi):
- Przygotowuje trzy tablice stron po jednym wa?nym deskryptorze w
ka?dej, daj?ce identyczno?ciowe odwzorowanie pierwszych 2 MB i 3aduje CR3.
- Definiuje GDT z trzema deskryptorami kodu - 16-, 32- i 64-bitowym.
- W3?czam PAE i PGE w CR4.
- W3?czam LME w EFER.
- Wy3?czenie przerwan.
- Przej?cie do trybu chronionego od razu z w3?czonym stronicowaniem.
- Daleki skok do kodu 32-bitowego - jeste?my w Compatibility Mode.
- Z kodu 32-bitowego daleki skok do kodu 64-bitowego.
- Z kodu 64-bitowego daleki skok do 16-bitowego, wci?? w Compatibility.
- Wy3?czenie stronicowania.
- Wy3?czenie trybu chronionego (nie mo?na razem ze stronicowaniem!).
- Daleki skok do 16-bitowego kodu w trybie rzeczywistym.
- W3?czenie przerwan.

Karol \"Zal\" Zalewski

6/13/2007 8:55:00 PM

0

Bernard pisze:

>
> Czemu nie u?ywacie FASMa lub najnowszego NASMa?
>

Kwestia za3o?en projektowych. Bazujemy na starym projekcie sprzed
kilku laty - 16b system operacyjny z trybem chronionym i segmentacj?.
Prowadz?cy prosi3, aby?my nie ingerowali zbytnio w to, co ju? jest.

>
> ?e co? Segmentacja jest zredukowana do minimum tylko w trybie
> 64-bitowym, w trybie zgodno?ci dzia3a jak dzia3a3a.
>

My?la3em, i? tryb kompatybilno?ci opisany w ksi??ce Intela (Vol. 3A
sekcja 9..8.5.3) jest w równym stopniu zubo?ony w kwestii segmentacji.
S?dzi3em tak z tego wzgledu, i? jego aktywacja polega na modyfikacji
bitów w rejestrze CS, który jest niezbedny do poprawnego dzia3ania
segmentów. Najwyra?niej pope3ni3em b3?d.

>
> No to co? namieszali?cie zdrowo.
>

Namieszali?my i usi3ujemy sobie z tym jako? poradzia bazuj?c na
do?wiadczeniu innych. Mo?e uda nam sie to jako? odkrecia.

>
> Mo?e i d3ugim, tylko ?e kompletnie nic nie napisa3e?...
>

Stara3em sie jak mog3em, ale wiadomo jak to jest, gdy osoba pytaj?ca
(tzn. ja) sama do konca nie wie o czym mówi.

>
> Nie ma "przej?cia z segmentacji do stronicowania". Jest segmentacja i
> jest stronicowanie, praktycznie niezale?ne od siebie.
>

Oczywi?cie jest to prawda. ?le sie wyrazi3em. Co mia3em na my?li?
Uzna3em, i? sam fakt tego, i? przed wej?ciem do trybu 64b korzysta3em
z segmentacji, a nie ze stronicowania mo?e miea wp3yw na to, co dzieje
sie pó?niej. S?dzi3em, i? jeszcze w trybie 32b powinienem wykorzystaa
32b stronicowanie, nastepnie utworzya kolejne struktury dla 64b
stronicowania i na koniec wykonaa sekwencje rozkazów niezbednych do
przej?cia w tryb 64b. Widze teraz, i? to co napisa3em nie mia3o
wiekszego sensu.

>
> Ja to robie tak (celem u mnie by3o napisanie najkrótszego programu typu
> .COM, który prze3?cza w tryb 64-bitowy i z powrotem do rzeczywistego,
> wiec to nie ca3kiem to, o co Ci chodzi):
>
> ...
>

Wielkie dzieki za to, i? zechcia3e? udzielia mi odpowiedzi pomimo tak
mgli?cie opisanego problemu. Z pewno?ci? oka?e sie ona pomocna podczas
zabawy z tym, co ju? osi?gneli?my.

Pozdrawiam,
Karol "Zal" Zalewski

Bernard

6/14/2007 4:34:00 PM

0

Karol "Zal" Zalewski wrote:
>> Czemu nie u?ywacie FASMa lub najnowszego NASMa?
>
> Kwestia za3o?en projektowych. Bazujemy na starym projekcie sprzed kilku
> laty - 16b system operacyjny z trybem chronionym i segmentacj?.
> Prowadz?cy prosi3, aby?my nie ingerowali zbytnio w to, co ju? jest.

TASM o ile mi wiadomo nie jest rozwijany, a jego linker ledwie dycha.
Nie wyobra?am sobie pisania kodu 64-bitowego w asemblerze, który ma
problemy nawet z mieszaniem kodu 16- i 32-bitowego. Mój program napisany
w YASMie zawiera kod 16-, 32- i 64-bitowy w jednym pliku, a transluje
sie jednym poleceniem.

Przej?cie z TASM na YASM/NASM jest 3atwe, a napewno przed3u?y ?ycie
projektu. Pisanie w nowych asemblerach te? jest o niebo 3atwiejsze ni? w
TASMie. ?e o jednostkach wektorowych ju? nie wspomne...

Wiktor S.

6/17/2007 7:52:00 AM

0

> ZacznÄ? zatem od poczÄ?tku. JakiÅ? czas temu rozpoczÄ?Å?em z grupÄ? kolegów
> ze studiów prace nad rozwojem prostego 16b systemu operacyjnego - w
> ramach zajÄ?Ä? z "Oprogramowania systemowego". System ten pisany w
> zupeÅ?noÅ?ci w Asemblerze, przy wykorzystaniu asemblera TASM, a
> uruchamiany z poziomu DOS (jako plik .exe) nie byÅ? trudny do
> modyfikacji. PosiadaÅ? już segmentacjÄ?, zarzÄ?dzanie przerwaniami,
> przejÅ?cie do trybu chronionego itp. itd. Wszystko oprócz
> stronicowania. Niemniej jednak przeksztaÅ?cenie caÅ?oÅ?ci tak, aby
> pracowaÅ?a w 32b nie stanowiÅ?o wielkiego problemu.
> KÅ?opoty rozpoczÄ?Å?y siÄ? tuż po tym, jak postanowiliÅ?my kontynuowaÄ?
> projekt w celu uzyskania prostego systemu 64b. Archaiczny asembler
> byÅ? i nadal jest tutaj pewnym utrudnieniem, ale nie to jest
> najważniejsze.

ale w jaki sposób chcesz później pisaÄ? 64-bitowy pod za pomocÄ? TASM-a?
Im wczeÅ?niej przejdziesz np. na YASM (albo coÅ? innego, NASM-opodobnego) tym
lepiej - sÄ? pewne istotne różnice w skÅ?adni, co ciÄ? bÄ?dzie kosztowaÅ?o trochÄ?
pracy.

> PS. PrzeglÄ?daÅ?em parÄ? grup dyskusyjnych i mam nadziejÄ?, iż *trafiÅ?em*
> w tÄ? odpowiedniÄ?. Z góry przepraszam, jeżeli nie trafiÅ?em. Mam również
> nadziejÄ?, iż kodowaniem i dÅ?ugoÅ?ciÄ? linii (70) nikogo nie porażÄ? ;]
> Jeszcze nie przywykÅ?em do zasad, którymi rzÄ?dzi siÄ? Usenet.

może pl.comp.lang.asm ?

--
Azarien