[SFIJ]

Idézet: cx.core - Dátum: 2006. jún. 15., csütörtök - 19:34

A szegmentált memóriacímzés az x86-on jelenlévõ formájában nem teszi lehetõvé több védett módú OS biztonságos futtatását egyazon gépen. Ehhez arra lenne szükség, hogy az egyes virtualizált gépek védett módjának 0. privilégiumszintjén futó kód számára is korlátozható legyen a fizikai memória bizonyos (más virtuális gépeknek kiosztott) területeinek elérése. Ezt az x86 szegmentált címzése nem teszi lehetõvé, mivel a 0. szinten futó kódnak (definíció szerint) "mindent szabad" (a deszkriptortáblázatokat írni, a szegmensregisztereket globális, "supervisor" típusú deszkriptorokra mutató szelektorokkal feltölteni, stb). Ilyetén virtualizációt a lapozás sem tesz lehetõvé (eredeti formájában), hasonló okok miatt (a 0. szinten futó kód módosíthatja a laptáblázatokat, feltöltheti a laptáblázat-címregisztert (CR3), stb).

igen ez a mai latasmod mellett mar igaz, csakhat volt/van ring0,1,2,3 1985-ben a szegmentalas meg divatban volt, vagyis az ibm koncepicoja, mikoris a meta-os egyeb OS-t tolt (IPL), ring 0-n laknak a virtualis szervizek, amikbol minden OS gazdalkodhat. Az OS a Ring1-re toltodik. Ha megnezed a linux IBm VM/ESA specifikus kernel reszeit, akkor valami ilyesmit latsz. Namost a budos helyzet az lett, hogy
a) nem tudta/akarta az intel a meat OS funkciokat letrehozni, itt ugye DOS, CP/M 86, xenix (kesobb sco unix)-rol volt szo
b) az allando kapuhivasok doglassuva tettek a mukodest
c) a 90-es evek elejeig az ment, hogy volt ugye a microsoft fele DPMI, ami egy katasztrofa ugye, mert nem igazi dolog, hanem valami olyasmi, hogy belepsz IA32 modba, kihuzatod a szegmenseket 4Gigara, van egy flat cimed, a RAM-ok birjak ameddig vannak, mikozben van egy EMM386.sys ami lenyegeben egy kapuhivas, es lapozgat neked memoriateruleteket, tovabba valoban szetszegmentalja fizikailag a virtualis dos gepeket. ennek a legokosabb implementacioja a quterdeck fele desqview volt, ami DOS-okat es ratoltott proggiat tudott valoban multitszk futtani, igaz a proggik kozott zerus interakcio, adatcsere lehetett.
d) jott linus torwalds meg az NT, amik lenyegesen kisebb igenyuek voltak (privilegizalt mod + lapozas)
e) A szegmens regiszterek koruli oromkodes az utobbi 4 evben aranykorat elte, PSE36, felfedeztuk ujra az EMS-t igaz mostmar valos 32 bites proggik szamara, ambator eletveszelyes dolog felhasznaloi program kezebe adni a memoria-kezeleset.

A virtualizacio sokkal primitivebb modon lejezelheto amugy, wmvare modra. a guest OS kernel futas kozben tabornokvedelmi hibakat okoz, amit egy, a host OS-be injektalt virtualis driver egyszeruen elkap, es leemulalja a priviliegizalt funkciokat.

Azért is tartom csökevényesnek, mert nem transzparens; a szegmensregiszterek minden szintrõl "láthatóak".

hehe igen, de meg tudom oldalni, hogy minden garazda csak a sajat szegmens regisztereit lassa, es ne lathasonn bele a masikeba

lenyeg ami lenyeg. az AMD azert hagyta el az AMD64 modbol a szegmens reisztereket, mert
a) a kutyanak sem kell
b) noveli a cimszamitas indirekcios szintjeit ezaltal lassitja a mukodest.

Idézet: cx.core - Dátum: 2006. jún. 15., csütörtök - 19:34

Megpróbálom összefoglalni, hogy mi vetette fel bennem a kérdést.
Ha megnézünk egy modern "complex" meg egy modern "reduced" ISA-t, akkor azt látjuk, hogy a nagy "összecsapás" során kölcsönösen tanultak egymástól. Pl. az x86-ba is bekerültek valamilyen szinten a másik oldal szívének szottya predikátumos végrehajtású utasítások (cmov, fcmov), vagy az a lebegõpöttyös összehasonlító utasítás, amely közvetlenül az ALU flageit módosítja (fcomi), nem az FPU-ban lévõket. De pl. az ARM procikba meg bekerült a Thumb utasításkészlet, amely a félszavas (:Ð) utasításaival nyilván az x86 drágaszágát, a nagyobb utasítássûrûséget hivatott megkaparintani.

ebben teljesen igazad van, az ISA-k olyanna valnak, amilyenre szukseg van. A SUN USIII-nak van olyan utasitasa, ami a regiszter file-ban ropteben leszamol egy 8x8-as (i)DCT-t. Egy ilyenre a leg elvetemultebb CISC-fanok is elgedetten csettinetenek a szajuk szelen a nyelvukkel

Idézet: cx.core - Dátum: 2006. jún. 15., csütörtök - 19:34

Ezek nyilván kiragadott példák csupán (ráadásul a saját szájízem szerint válogatva), de az x86-64 bõvítéseivel együtt nézve számomra egyértelmûen radikálisabb változásokat jeleznek elõre. Ki tudja, talán még azt is megérjük, hogy a TLB miss az eljövendõ x86-64-eken is egyszerûen csak megszakítást fog okozni, ahelyett, hogy a laptáblázatok HW-es bogarászása indulna meg.

Ennel en kisebb igenyu vagyok. nekem mar azis jol esne ha a regiszterek beteges harmassaga mexunne, ugymint egesz regiszter, lebegopottyos regiszter, xmm regiszter. legyenek csak 128 bites memoriacellak es az hogy a benne levo adatot hogyan kell ertelmezni az kizarolag a raapplikalt utasitas dontse el.

[cx.core]

Idézet: SFIJ - Dátum: 2006. jún. 15., csütörtök - 22:47

A virtualizacio sokkal primitivebb modon lejezelheto amugy, wmvare modra. a guest OS kernel futas kozben tabornokvedelmi hibakat okoz, amit egy, a host OS-be injektalt virtualis driver egyszeruen elkap, es leemulalja a priviliegizalt funkciokat.

Igen, ilyet már volt szerencsém látni egész közelrõl. Ennek szerintem annyi a szépséghibája, hogy sajnos van olyan x86 utasítás (smsw), amellyel akármelyik szinten futó kód megtudhatja (mivel nem okoz kivételt), hogy védett módban van-e a processzor. Tehát lehet olyan kódot írni, amely csak valós módban hajlandó elindulni, ezért aztán a VMWare-nek beletörik a bicskája. Azt persze lehet, hogy ezeket az utasításokat futtatás elõtt megpróbálja felderíteni, de hadd ne mondjam, hogy ezeknek az elrejtésére x86-on hányféle mocskos kis trükk létezik.

Én egyébként a virtualizációs megoldások közül a teljesen SW oldalit preferálom, amit az exokernelek meg az L4-like mikrokernelek ún. "LibOS" megközelítése képvisel.

Idézet

hehe igen, de meg tudom oldalni, hogy minden garazda csak a sajat szegmens regisztereit lassa, es ne lathasonn bele a masikeba

Gondolom lokális deszkriptortáblázatokkal. De ehhez is az kell persze, amit fentebb írtál.

Idézet

lenyeg ami lenyeg. az AMD azert hagyta el az AMD64 modbol a szegmens reisztereket, mert
a) a kutyanak sem kell
b) noveli a cimszamitas indirekcios szintjeit ezaltal lassitja a mukodest.

Ez világos, és szerintem jó húzás volt.

Idézet

Ennel en kisebb igenyu vagyok. nekem mar azis jol esne ha a regiszterek beteges harmassaga mexunne, ugymint egesz regiszter, lebegopottyos regiszter, xmm regiszter. legyenek csak 128 bites memoriacellak es az hogy a benne levo adatot hogyan kell ertelmezni az kizarolag a raapplikalt utasitas dontse el.

Ezt, látod, ki is hagytam, pedig általában ezzel szoktam kezdeni, amikor sorolom, hogy mit szeretnék Karácsonyra.

[SFIJ]

Idézet: cx.core - Dátum: 2006. jún. 15., csütörtök - 22:24

Tehát lehet olyan kódot írni, amely csak valós módban hajlandó elindulni, ezért aztán a VMWare-nek beletörik a bicskája.

ebben igazad van, de ez kvaz 16 bites uzemmodot jelent, ezeket a windows jelenleg vagy a dos emulaciojan vagy a wovexec-en keresztul futtatja (korai win kodok). Ha ezek sem valnak be, akkor megprobaljuk a wmvare-t. ha mindez kudarcot vall, akkor a szoffert hasznalhatalannak nyilvanitjuk es eldobjuk. illetve nem. akkor marad a BOCHS, ami egy telejesen szofferes x86 emulator, es inditaskor konfigolhato hogy milyen ISA-t emulaljon A BOCHS-sel, amikor nagyon muszaly volt, futtatam sun ultra 5-on nativ win9x szoftokat, (offisz 97)

[cx.core]

Idézet: SFIJ - Dátum: 2006. jún. 23., péntek - 17:04, AMD Hammer - negyedik rész

az OOP szofferek sajnos katasztrofalisan rosszul parhuzamosithatoak. mindezek mellet nagymeretu index-tablakat igenyelnek (virtualis metodusok) igyha elhajgyjuk az IA32-bol az indexelt cimzesi modokat, annak bizony ara van.

Az eredeti témafelvetésem célja éppen az lett volna, hogy nézzük meg az említett változási lehetõségeket mindkét szemszögbõl. Mi szól ellene (azon kívül persze, hogy maga a változás ellene van az x86 filozófiájának )? Mi szól mellette? Melyik esetében lehetséges, hogy egy technológia, programozási paradigma, stb. jövõbeni megjelenése/megerõsödése meg fogja követelni?

Sebaj...

[SFIJ]

Idézet: cx.core - Dátum: 2006. jún. 23., péntek - 17:01

Az eredeti témafelvetésem célja éppen az lett volna, hogy nézzük meg az említett változási lehetõségeket mindkét szemszögbõl. Mi szól ellene (azon kívül persze, hogy maga a változás ellene van az x86 filozófiájának )? Mi szól mellette? Melyik esetében lehetséges, hogy egy technológia, programozási paradigma, stb. jövõbeni megjelenése/megerõsödése meg fogja követelni?

Sebaj...

cx.core nemtok erre valaszolni. ma az ipar java es c# kodot akar es szeretne irni. ezek oop, sot meg rosszabb, mert interpretalt, heap-buzi, managed adatstrukturaval rendelkezo nyelvek, ahol az adatok elettartama nem tervezheto, hanem fire-and forget elvu, es a garbage collector megmajd eldob mindent ami eldobando. az ilyen szoffer olyan kodot eredmenyez mmi rosszul parhuzamosithato, es a load/store architekturak szamara is agyrem.

a kozeljovo az ilyen interpretalt nyelvek burjanzasat hozza majd, meg persze masodviragzasnak indultak a funkcionalis nyelvek is.

ezekkel a trendekkel csunyan szembepisil mindaz, amerre a processzorok fejlodese hat. najo pontositok. a processzorgyartok rajottek, hogy nagy penz van a szorakoztato iparban, igy az ilyeten igenyeket elegitik ki leginkabb manapsag. csak ez a boom is lassan veget er...

Szerkesztette: SFIJ 2006. 06. 23. 17:38 -kor

[d n . r]

Most olvastam egy hírt, amirõl eszembe jutott ez a nyitó hozzászólásom:

Idézet: dnr - Dátum: 2004. jan. 3., szombat - 1:18

(Mielõtt ebbe belevágnék, pontosabban meghatároznám, mit értettem fentebb elkülönült alatt: nem mást, mint hogy a hardvert (esetünkben a processzort) pontosan ide és nem máshová fejlesztik. Ez egyben azt  jelenti, hogy ennek a piacnak kell eltartania a fejlesztés roppant tetemes költségeit!)
És hogy ezt miért kérdõjelezem meg, arra a grafikus chip-ek piacáról hozok analógiát. Jelenleg úgy néz ki, hogy a professzionális kártyák piacát is az ATI és az nVidia uralja, méghozzá úgy, hogy a profi kártyákat pontosan ugyanazokra a chipekre építik, mint amikre a kommersz (azaz nagy tételben eladható, tömegesen gyártott) kártyák épülnek.
(Két zárójeles megjegyzés. Egyrészt van még a 3DLabs, azonban a tulajdonos a Creative, és múlt tavasszal fel is röppent, hogy a P10re gémer kártyát IS kivánnak építeni (aztán nem lett belõle semmi, valszeg mert nem lett volna elég a teljesítménye a gémer piacon. Viszont emlékeim szerint lett belõle "kommersz" multimédia-verzió). Kérdés, mit hoz itt a jövõ.

Na, hát már nem kérdés:

https://www.hwsw.hu/hirek/32521/3dlabs_crea...processzor.html

Idézet

A 3Dlabs aztán idén tavasszal azt közölte, hogy elhagyja egykori vadászterületét, a professzionális videochipek piacát és a jövõben a mobil eszközök számára kíván megoldásokat fejleszteni. A cég szerint a multimédiás és 3D alkalmazások futtatására képes hordozható eszközökben, például tenyérgépekben és okostelefonokban sokkal nagyobb a piaci potenciál, mint a professzionális munkaállomásokban. A vállalat nemrég kezdte meg elsõ mobil terméke, a DMS-02 nevû lapka próbagyártását.