win95 swap a ramdrive-ban

[VF]

Thus spake Auth Gábor:

>  Az OS MMU része azért is érdekes ebbõl a szemponból, mert a 

Igaz, de a proci MMU resze ugyanaz, csak ezt cacheli.
Kulonben lehetne minden egyes memoriamuveletnel a kernellel fordittatni a
cimet, kegyetlen lassu lenne. Ehelyett az egyszer hasznalt lap bekerul a
proci hardveres MMU-tablajaba. Termeszetesen minden context switchkor
ki kell pucolni onnan, mint a sima data es instruction cache-t is.

> Másrészt a címtartomány nagyon nem egyezik. Fájlrendszerben lazán 
> kezelünk jelenleg egy fájlszerveren ~2TBájt kapacitást hardveres RAID5 
> tömbökbõl szoftveresen összefûzött (VVM modullal kezelt) egybefüggõ 
> tárhelyet. Sem a processzor, sem az oprendszer MMU táblája nem képes 
> ekkora címtartományt kezelni 32 bites rendszeren. Így nem is lenne képes 
> visszatölteni a kilapozott programkódot a lemez bármelyik részérõl. 

Ez attol fugg, mert az x86 szegmenses felepitese pl tudna, csak ezer mas
baja van. Egyebkent pedig csak processenkent kell szamolni a 4G limittel,
a sok process memoria-hasznalata egyutt tullepheti a 4G-t siman.
A VMS valamelyik verzioig 1G-t adott egy processnek, az ujabbak mar 4G-t.

>  Én tudom... a programkódot nem lehet ,,csak úgy'' betölteni a memóriába, 
> hanem elõtte címfordítást kell készíteni, attól függõen, hogy milyen 
> címre töltõdött be, mivel általában tele van abszolút címzésekkel a 

Ez nem feltetlenul igy van, OS-fuggo! 2 megoldas terjedt el: az egyiknel a
progi valoban akarhova toltodhet, es ha vannak benne sajat magaba mutato
abszolut cimzesek, akkor azokat relokalni kell. Igy mukodik pl az AmigaOS.
Nem biztos hogy vannak abszolut cimzesek, jo assembly nyelvvel rendelkezo
processzor eseten (pl m68k) csak nagyon lamer programozas eseten van ra
szukseg, egyebkent a movea #cim,.. helyett lea cim(pc),.. hasznalhato, es
akkor nincs szukseg relokalasra. Igy meg szebb is lesz a program szerintem.
Csak bizonyos elore definialt strukturak eseten van eros kenyszerito ero az
abszolut cimzes hasznalatara, ez is kikuszobolheto lenne. Az alabbi mindket
program tartalmaz ilyen strukturakat, de a kisebbnel dinamikusan allitottam
elo oket.

New Shell process 8
Ram Disk:>showhunk sys:exe/copper-demon
ShowHunk v2.0 Copyright (c) 1993 Jim Cooper
 Original ShowHunk v0.1 (c) 1992 $#%!

Hunk layout of file "sys:exe/copper-demon" (15812 bytes)

        hunk_header
          #of hunks: 1
HUNK 0  hunk_code: 15776 bytes

Position independant code!

Ram Disk:>showhunk vss:vss
ShowHunk v2.0 Copyright (c) 1993 Jim Cooper
 Original ShowHunk v0.1 (c) 1992 $#%!

Hunk layout of file "vss:vss" (120408 bytes)

        hunk_header
          #of hunks: 2
HUNK 0  hunk_code: 1644 bytes
        hunk_reloc32
          1 reloc entry for hunk #0
HUNK 1  hunk_code: 114892 bytes
        hunk_reloc32
          946 reloc entries for hunk #1


Ram Disk:>

A masik megoldas, hogy a programot fix virtualis cimre toltjuk, igy
relokalasra nincs szukseg, fizikailag termeszetesen teljesen mashova fog
kerulni a program. Linkelni attol meg lehet hogy kell a programot, pl a
dll hivasokat ra kell iranyitani a megfelelo kodreszletre, stb...
Ha ilyen nincs benne, relokalasra nincs szukseg. Pl C64 basic, CP/M, DOS,
VMS, talan a windows is?

>  Elhiszem, hogy egy évtizedes VMS rendszer esetleg így csinálta, de most 
> a nagygépes rendszereknél az igények és a lehetõségek túlhaladták ezt a 
> módszert.

Inkabb a lehetosegek :) Mert igeny lenne ra, sokkal hatekonyabb.
Most adott esetben egy nagy file inditasa egy vinyorol vinyora torteno,
logikailag felesleges masolassal kezdodik, ami agyrem.

>  Nekem az a néhány is elég lenne... ha megmutatnád...

Jo vicc... Keresd meg ha erdekel.

> Frank O'Yanco -=- Mobil +36-70/312-1856 +36-30/368-7792 -=- ICQ: 49179141

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
"Rogton maga jon, csak elvittek elezni a bardot"