Még volna itt valami. Lehet hogy félreértettelek téged LGB, de azt tudnod kell, hogy a 386-os prociktól felfelé MINDEN alkalmazásnak (programnak, processznek) 4GB memória állt rendelkezésre, mert a processzor ennyit tudott megcímezni. Nem volt szükség lapozásra.
Ezt rosszul tudod. Csak eppen mas fajta lapozas, nem ugyanaz nyilvan mint amit az EP a Dave-ben csinal
A 386-os maga kozvetlenul meg tud(na) cimezni 4Gbyte memoriat igen, de az un virtualis cimtartomany ennel joval nagyobb, mivel egy lapot lehet jelolni nem letezonek is. Plusz, mivel 4Gbyte memoria ritkan volt azert 386-os rendszerben meg, eleve ezt csinaltak, ez az un swapping megvalositasanak a hw alapja, akkor egy nem letezonek jelolt lap hatasara kivetel generalodik, amit az OS lekezel, es pl a disk-rol betoltodik az aktualis lap. Nem tudom miert irod, hogy 386-oson nincs szukseg lapozasra: pont az a lenyege, minden modern OS, modern CPU-n lapozast hasznal! Csak eppen lehet, belekeveredtel a fogalmakba, mert - ahogy irtam - ez a lapozas _NEM_ az a lapozas, ami EP-ben van! Ez kis felreertesre adhat okot.
Itt jon a kepbe, hogy nem akartam azt mondani, hogy implementalni kene elsore egy "advanced MMU" (a "386-os ertelmeben vett" lapozassal egyutt) jelleget, azert mondtam, hogy mar az is elorelepes lenne, ha csak az EP ertelmben vett lapozasnal egy-egy 16K-s szeletre remondhatnad, hogy a CPU szamara az read-only, igy nem tudod felulirni veletlenul legalabb. Ettol persze ez teljesen mas jellegu dolog, mint 386-oson, ahol egy lapra azt mondod, hogy read-only, azon kivul, hogy a fogalom hasonlit, teljesen mas implementaciorol van szo, termeszeten!
Azért mondom, hogy mindegyik programnak (processnek), mert képes volt elszeparálni egymástól a memóriaterületeket, és ami A programnak 0x00ba13A2h memóriacímen található információ az B proginak már teljesen más értéket adott ki ugyanazon címen, nyilván azért, h. ne láthassák egymás adatait, mert akkor ha képes felülírni, beláthatatlan hibához vezet. Itt viszont már beszélhetünk "lapozásról" amikor az OP rendszer átadja mondjuk 100us idõre a másik alkalmazásnak az irányítást, akkor a neki megfelelõ memóriakörnyezetet is felépíti.
Ez igy nem teljesen korrekt, nem epiti fel, csak hasznalja. Az kisse "draga" lenne, ha a laptablakat ujra kene epiteni minden context switch-nel
En pont errol beszeltem, hogy alapvetoen azert nem kene elsore egy uj 386-ost tervezni Z80 utasitaskeszlettel
elsore az is jo, ha a meglevo dolgokat lehetne kisse "finomitani". Itt meg arrol van szo, hogy a Z80 alapvetoen 16 bites cimbusszal rendelkezik. Ha mindenaron - bar santito - analogiat akarunk allitani, mondhatjuk, hogy a fenti peldad igaz EP-re is: amit a Z80 lat pl a 0x3AE2 cimen, az lehet mindig mas, attol fugg, mi van oda "belapozva". Persze ismetelten: vigyazzunk ezzel a "lapozas" fogalommal, mert problema, hogy azert 386-oson ez nyilvan nem ugyanazt jelenti, mint EP-n (es persze tovabbi elteres, hogy 386-oson ez a CPU resze, EP-n pedig nem, a Z80 cimbusza 16 bites, csak epp a Dave "besegit" a hianyzo cimbusz bitek eloallitasaban).
- Mielõtt belekezdek szeretném kiemelni, hogy a Win95/98 másképp mûködött mint a Windows NT, az elsõ DOS alapú volt nem volt benne igazi újítás, nem foglalkozok vele. Láthatjátok is, hogy amint lehetett számûzték, és minden mostani Windows-os OP rendszer NT alapú
Jah, win 2000 elotti dolgok azok vegulis DOS felett futo, protected mode "shell" voltakeppen nemi GUI-val
Utana mar NT alapokon nyugvo rendszerrol van szo, amit erdendoen szerver OS-nek fejlesztettek, es maga a kernel nem is lenne rossz (pl VMS fejlesztok is reszt vettek benne). Csak epp annak amit tud, nagyon kis reszet hasznalja ki a windows-ban ami 'felette van' es kisse tonkrevagja a koncepciot ...
Szóval, mivel akkor még nem volt ennyi (4GB) EDO-RAM elérhetõ ezért a Windows NT virtuális memóriát használt, amit a merevlemezen tárolt. És amikor a program hozzáférést kért ehhez a memóriához, azon belül pedig ahhoz a részhez, ami éppen nem volt a RAM-ban, az Operációs Rendszer betöltötte a merevlemezrõl a rendszer-memóriába amire éppen szüksége volt. Ezen kívül a felsõ 2GB-ot úgy emlékszem nem is használta, a kompatibilitás miatt, ugyanis léteztek olyan processzorok, amik a 2GB feletti részt nem támogatták (DEC alpha)
Nem kell elmagyarazni, irtam OS-t 386-osra mar, szoval tisztaban vagyok a mukodesevel
Amit irtal, arrol irtam fentebb: egy lapot megjelolsz nem letezonek, ez ugy muxik. Amugy az most is gond akar pl Linux alatt is, ha 4Gbyte ram-od van, mert a cimtartomanyt fel kell osztani a kernel es a userspace kozott. Ilyenkor (vagy meg tobb ram eseten) jon a kepbe pl a PAE az ujabb x86-okon, ha mindenaron 32 bites rendszer kell, ami egy ujabb absztrakcios reteget jelent a cimlekepezesben valojaban.
Természetesen nem volt olyan program, ami lefoglalt volna ilyen tetemes mennyiségû memóriát, így sosem volt kihasználva teljesen.
Mindezeket csak azért tudom, mert most tanulok Windows-NT-t programozni, és a memória lefoglalás esetén fontos, hogy átlássuk a mûködést.
Vannak azert erdekes kerdesek minden OS eseten, pl memory overcommit stb, engedjunk-e tobb memoriat foglalni mint a fizikai rendelkezesre allo (hisz az valoszinu eleg durva swapolast - melleseleg szvop-nak kell ejteni, nem en irtam el, hehe) eredmenyezne kesobb.
Na bocsi, csak azert mentem bele ilyen reszleteseggel, mert ugy erzem, felreertettel, illetve osszemostad a "lapozas" fogalmat EP es 386 kozott. Remelem sikerult tisztazni, hogy mit is akartam mondani.