Bejelentkezés

Keresés a fórumban

Kulcsszó
Hálózatok
  • Oldal:
  • 1
  • 2

TÉMA: Tervezzünk virtuális számítógépet!

Tervezzünk virtuális számítógépet! 2016 dec. 17 01:37 #2115

  • FossilCodger
  • FossilCodger profilkép
  • Nem elérhető
  • Arany fokozatú fórumozó
  • Hozzászólások: 201
  • Köszönetek: 6
  • Karma: 0
Bocs és medve meg minden, jobb alfórumot nem találtam rá. Igaz hogy ez szoftver, de annyiból hardware, hogy emuláció. Legalábbis annak szánom.

Tehát, tervezem egy elképzelt számítógép „leprogramozását”. Magyarán, emulálni/szimulálni (bevallom, bizonytalan vagyok benne, melyik szó a legjobb ezesetben...) egy elképzelt számítógép működését. Nyilván azonnal felmerül a kérdés, milyen MÉLYSÉGIG akarom emulálni?! Elvileg le lehetne menni akár az egyes áramkörök szintjéig is, csak aztán győzzük kivárni amíg bebootol...

Nos, én inkább csak olyasmire gondoltam, ami nagyjából egy C-64 emulátor részletessége. Ettől azonban még a feladat felettébb érdekes, tudniillik egy ilyen project esetében mindenekelőtt megtervezhetünk egy tökéletesen a mi tetszésünk szerint való assembly nyelvet, erre írhatunk saját fordítóprogramokat, szkriptnyelveket, ezekben saját shellt, meg mindent amit csak akarunk... nyilván, meg kell írni a gépünk operációs rendszerét is cakumpakk, feladatütemezővel, megszakításokkal, akármikkel... ÓÓÓÓÓÓÓDEPOMPÁS! Mármint príma szórakozás!

Nyilván azért itt is akadnak elmosódott területek. A memóriakezelés miként legyen? Úgy értem legyen kijelölve egy fix memóriaterület amiből nem tud kitörni a virtuális gép, s ezen belül legyen az ő „memóriája”, amiből allokálhat a kernele, vagy a memóriakezelést a host rendszer végezze, ezesetben mindig akkora amekkora épp szabad a host rendszeren belül? Ez utóbbi megoldás nemcsak nagyobb memóriamennyiséget biztosítana de gyorsabb is volna, ellenben nyilvánvaló biztonsági kockázat.

És még RENGETEG efféle kérdésről szó van.

E topik célja épp az, hogy itt ezeket KULTURÁLT hangvételben (már ha ez elképzelhető... :( ) átbeszélhessem azokkal, akiket esetleg érdekel e téma. NEM AZ A CÉL HOGY MÁSOK PROGRAMOZZANAK HELYETTEM. Csak dumálni a témáról kötetlenül.

Egyelőre a dolog olyan készültségi fokon áll, hogy van egy rendkívül hatékony, robusztus függvénygyűjteményem, rengetegszer tesztelt funkciókkal, ezeket használtam nagyrészt korábban a programnyelveimhez is. Ezeket használtam azon progikhoz is, amik a jelenlegi desktop környezetemet működtetik, magyarán mindent ezek csinálnak a szűken vett ablakkezelést kivéve ami a DWM dolga. A másik topikban említett szótárprogramomat is e rutinokkal írtam.

Készen van továbbá a leendő virtuális gép virtuális grafikus kártyájának emulációja valami alapszinten. Ezalatt azt értem, hogy van egy olyan rutincsomagom, aminek hála úgy tudok grafikus képernyőt kezelni, hogy az X abból semmi mást nem érzékel csak egy pixmapet amit periodikusan kirajzol az ablakba. Gyakorlatilag tehát egy virtuális videomemóriát kezelhetek a magam programjaiban. Maga a megjelenítés egy külön szálon történik, azaz a parent processz idejéből nem vesz el semmit, azt nem lassítja. Igazából azonban nem 2 hanem 3 szál van, mert a megjelenítő szál, az két szál, az egyik végzi a tulajdonképpeni megjelenítést, a másik pedig a renderelést. Ezalatt az értendő, hogy van egy külön „grafikus memóriaterület”, amire a pixeles kiirogatás megy, lesz egy másik ami a karakteres konzolok dolgait tárolja, meg egy harmadik is ami olyasmikre lesz dedikálva hogy sprite-ok, effélék, s a renderelő szál ezekből állítgatja majd elő a képet amit a kiírószál megjelenít.
Mindebből egyelőre csak a pixeles memóriarész rutinjai vannak leprogramozva, meg az egész keret, a „csontváz”, szóval ami vezérli ezt a mindent. A grafikai rész már oké, már rajzoltam ki vele gyönyörű Mandelbrot-fraktált, meg más függvényeket is, meg tudok jeleníteni rajta bármilyen PNG képet, tudok képernyőképet készíteni a teljes monitoromról vagy csak az adott ablakról szintén PNG formátumban, meg egy csomó minden más is megvan már. Még részleges ALSA-integráció is (az persze nem a grafikus csomag része) mert megvan a hangerő szabályzása meg a mute/unmute is.

Na most a következő nagy lépés tehát a KONZOL osztály megvalósítása lesz, bitmapped fontkészletek kiírására. És épp itt lehetne az érdeklődőknek kifejteni a véleményüket!

Ugyanis a következő lehetőségek merültek fel bennem:
—1. A KONZOL a MONITOR osztály beágyazott objektuma. Ez nekem nem tetszik, mert akkor megszegném azt az elvet hogy a grafikus kártyám (az emulált) csak pixeleket jelenít meg, más nem az ő dolga. Nem szeretem a túl okos(kodó...) osztályokat, azokkal mindig baj van. A programnyelveim írásakor ha valamit tanultam egyáltalán, hát az biztos az volt hogy egy osztálygyűjtemény akkor jó, ha az osztályok egymással „gyengén kapcsoltak”.
—2. A KONZOL egy külön osztály, s ő ír a képernyőre. Ezesetben nem különül el a grafikus kép attól, ami a karakteres képernyőről keletkezik, s ez funkcióvesztés. Vagy a KONZOL egy külön memóriaterületre generálja le a karakterekből képzett bitmintákat, s majd a renderelő szál ezt összeszerkeszti a grafikus képernyő tartalmával. Ez tökéletesen járható megoldás, ezesetben azonban a KONZOL osztály valamiképp kell hogy kommunikáljon a megjelenítést végző MONITOR osztállyal, ami vagy azzal jár hogy kibővítem valamiféle szerverképességgel hogy üzengethessenek egymásnak, vagy legalábbis kell hogy legyen minden KONZOL példányomnak egy olyan shared memory szegmense, ami közös a MONITOR osztályéval. Hááát, ööö, izé.... oké, belefér, meg tudom oldani, de ez olyan hogyismondjákos... szóval, nem szép, na! (Ennek ellenére bevallom, még a számos rossz megoldás közül eddig ez tetszik a legjobban, „tetszés” alatt azt értve hogy ezt tartom a kisebbik rossznak).
—3. A KONZOL példányai megkapják az aktuális MONITOR példány referenciáját, aztán közvetlenül birizgálják annak mezőit, vagy jobbesetben csak annak publikus metódusait hívogatják. Hát ettől is a hideg ráz ki, mert bár elvileg ez egy tökéletesen legális megoldás, de ez azzal járna hogy a KONZOL objektumom muszáj hogy ismerje a MONITOR osztály felépítését, legalább annyit belőle amire ráfogjuk hogy „publikus interfész”. És nekem ez se tetszik. Végülis mi KÖZE van egy konzolnak a grafikus megjelenítéshez?! Ideális esetben semmi...

Mindez bonyolódik azzal, melyik osztály felelősségi körébe tartozzék a fontkészlet kezelése, ismerete. Elvileg a KONZOLnak ehhez se kéne hogy köze legyen, az karakterkódokkal kell törődjön, nem bitmintákkal. Ha azonban ezt áttesszük a MONITOR felelősségi körébe, azonnal olyan undorító dolgokkal kell foglalkoznia, mint a fontkészlet betöltése, ami pedig fájlkezeléssel jár, mint beolvasás meg ilyesmik, holott egy grafikus kártyának ehhez rohadtul semmi köze NEM SZABAD hogy legyen! (pláne ha a file nem is létezik, nem olvasható, stb, hogyan ad hibajelzést?!) A betöltött fontkészlet meddig marad a memóriába töltve? Naplóznia kéne mint erőforrást hogy melyik konzolnak van még rá szüksége! Szóval szörnyű katyvasz, na.

Tehát mint látszik, a legalapabb alappal megvagyok, mert a pixelek kirajzolgatása, képek, ilyesmik mennek, a szálkezelés is perfekt, gyakorlatilag oké az interprocessz kommunikáció (én magam programoztam le cakpakk, nem használtam pthreadet meg más effélét...), de a jövőt illetően az „útkeresés fázisában” vagyok, nem mintha túl nehéz volna amit meg kell oldani, csak nem vagyok még biztos benne hogyan volna a legszebb, legelőkelőbb, s gondoltam - nem tanulván korábbi csalódásaimból, vagy ha úgy tetszik amíg élünk remélünk - hátha el lehet itt értelmesen beszélgetni effélékről egyesekkel, mert ez oly szép és csodálatos téma, hogy nem tudom elhinni hogy másokat ne érdekeljen! Akarommondani, az eszemmel tudom én azt jól hogy biztos nem sokakat érdekel, de „nem érzem át”, fel nem tudom fogni hogy lehet az ha valakit ez nem érdekel, s ezért úgy vélem igenis kell legyen olyan akit mégis érdekel.

Ha meg nem hát nem, oké, elcsesztem 15 percet az életemből amíg ezt megírtam ide.

Akartam csatolni ide egy képet a Mandelbrot-fraktálomról is, de 718K és így nem engedte a rendszeretek.

Programming is like using toilets; you can't say you are done until paperwork's finished!
Nyilvános megtekintési jogosultság letiltva.

Tervezzünk virtuális számítógépet! 2016 dec. 17 04:42 #2116

  • FossilCodger
  • FossilCodger profilkép
  • Nem elérhető
  • Arany fokozatú fórumozó
  • Hozzászólások: 201
  • Köszönetek: 6
  • Karma: 0
Továbbmorfondírozva a dolgon, és számolgatva, az jött ki, hogy talán úgy járok a legjobban, ha egyszerűen kijelentem, hogy a virtuális grafikus kártyámnak márpedig nem 1, hanem 257 „képernyője” van. Az egyik a root, és igazából mindig ezt látjuk. A másik 256 meg egy-egy olyan memóriaszegmens, amibe írkálhatunk, s ezeket összerendereli a harmadik szál a rootra ami látható. Természetesen, ezen al-képernyők mérete szabályozható, amint az is hol jelenjenek meg a roothoz viszonyítva, a maximális méretük azonban ugyanakkora mint a root képernyőé.
Ezeket azonban nem Window-nak nevezem el mert arról a szóról mindig a Windows jut az eszembe. Ezeknek a neve nálam AREA lesz. Vagy VISION. Még nem tudom melyik mellett döntsek...
Ezekre történik majd az írás a KONZOL osztályommal, persze előbb egy KONZOL példányhoz hozzá kell rendelni egy VISION értéket. Minthogy ezekből ugye 256 lehet, ez egy unsigned char érték. Kiszámoltam, jelenleg 1600×800 felbontással nyomulok a virtuális gépemnél, ez azt jelenti hogy jó sok lesz a lefoglalt terület, de végeredményben (TrueColor színskálát használok, más nem lesz) megúszom kevesebb mint másfél giga memóriafoglalással. Ez nem sok, figyelembe véve hogy a gépemben 16 giga van, elvégre azért van a RAM hogy használjuk, manapság meg már a nagyon tré gépekben is szokott lenni legalább 4 giga.
Aztán ezek a - mondjuk - VISION -ok kell hogy használva legyenek nemcsak KONZOL, de SPRITE célokra is.

Egyelőre még ez tűnik a legjárhatóbb útnak. Vagy legalábbis, a LEGÁLTALÁNOSABBNAK. Így a MONITOR osztályomnak garantáltan marhára semmit se kell tudnia holmi karakteralakokról, fontkészletekről, más baromságokról. Nem az ő reszortja. A fő képernyőt kell ismernie, meg hogy épp az egyes VISON-ok balfelső koordinátája mennyi a főképernyőhöz képest, s mekkora terület kell látsszék belőlük, egyáltalán, „be vannak-e kapcsolva”. És kész, slusszpassz.

Jó, hát tudom én, nem egy memóriakímélő megoldás... De épp tegnap néztem, vehetnék alig több mint 1700 dollárért már 32 giga RAM-mal rendelkező ThinkPad laptopot is... (de nem veszek, a 16 giga elegendő...) Ehhez képest hogy ez másfél gigát se igényel, simán elviselhető.

Programming is like using toilets; you can't say you are done until paperwork's finished!
Nyilvános megtekintési jogosultság letiltva.

Tervezzünk virtuális számítógépet! 2016 dec. 20 19:48 #2117

  • FossilCodger
  • FossilCodger profilkép
  • Nem elérhető
  • Arany fokozatú fórumozó
  • Hozzászólások: 201
  • Köszönetek: 6
  • Karma: 0
Látom a dolog reménytelen. Nincs érdeklődés egy ilyen érdekes téma iránt sem. Hm, ez mindennél ékesebb jele annak, hogy a Világ megérett a pusztulásra! Csak a népesség növekszik, az intelligencia összege optimista becslések szerint is legfeljebb állandó...
Mindenkit csak a könnyű, kulcsrakész megoldások érdekelnek, alkotni pedig senki se akar. Bezzeg az én időmben (úgy értem amikor fiatal voltam) amikor hatszor is át kellett írjak egy 4K nagyságú assembly rutint hogy találjak még néhány szabad bájtot egy új funkcióhoz, mert éppen pontosan 4K helyem volt csak az egészre és nem több... Hiába van most eszméletlen nagy memóriám és sebességem az akkorihoz képest, de a lelkem mélyén visszasírom azokat az időket. Az volt az Igazi programozók - mondjuk így - HŐSKORA...

Na semmi baj, túlélem. Hiába, a mai nemzedékeket már teljesen lezüllesztette a Windows, az OSX, sőt az Ubuntu meg az Android is. Meg még a normálisabb disztrókban is az olyasmik hogy Systemd, KDE, Unity, MIME típusok, automount, grafikus fájlkezelő programok... A legtöbben már el se tudják képzelni hogy úgy kezeljenek egy számítógépet hogy abban nincsenek IKONOK... Bameg, én még úgy tanultam hogy az „ikon”, az egy egyházi fogalom, görögkatolikus szentképet jelöl. De még a programozók is elkurvultak, a legtöbben már úgy vélik a C egy „nehéz” nyelv, persze a C++ is, ne is tanítsuk kezdőknek, mert még elvesztik az intellektuális szüzességüket... Pythont nekik, ez a véleményük! Meg valami webes lófaszt hogy azonnal legyen „sikerélményük”! Persze aki ezeken szocializálódva indult neki a programozásnak, nem is fogja soha megtanulni a C/C++ nyelvet, mert tényleg hozzászokik a könnyű sikerhez de annyi baj legyen, majd írnak progit mindenféle „köztes rétegeket” felhasználva, nem baj hogy lassú lesz és memóriazabáló... És igazuk is van, a hülye felhasználók többsége úgyse ért hozzá hogy lehetne jobb is.

Hülyül a világ el rekordsebesen, én mondom.

Na jó, befejezem, felesleges is a szócséplés, úgyis reménytelen az egész mert vakoknak magyarázom a színeket...

Programming is like using toilets; you can't say you are done until paperwork's finished!
Nyilvános megtekintési jogosultság letiltva.

Tervezzünk virtuális számítógépet! 2016 dec. 21 15:59 #2118

  • FossilCodger
  • FossilCodger profilkép
  • Nem elérhető
  • Arany fokozatú fórumozó
  • Hozzászólások: 201
  • Köszönetek: 6
  • Karma: 0
Na csak halkan szólok, hogy a korábban ecsetelt módszer MŰKÖDIK! Igaz még nincs se konzolom, se sprite-jaim, de a 256 VISION gyönyörűen működik, tudniillik letesztelhettem őket azzal, hogy kiraktam rájuk PNG képet, s ezeket mozgattam kurzorbillentyűkkel a „háttérkép” felett. NINCS SZELLEMKÉP, tökéletesen tiszta a mozgás, a sebesség is oké, még akkor is ha a mozgatott kép mérete ugyanakkora mint a teljes képernyőm, tudniillik 1600×800 pixel. (És persze TrueColor). Ja, hogy miként mozgatható ha ugyanakkora? Nos úgy, hogy beúsztatható bármelyik irányból, hehehe...

És a legszebb az egészben, hogy folyamatos mozgás mellett is, a processzorterhelés csak kb 0.6, ami azért igazán elhanyagolható, mert az 1-et se éri el, holott a gépem akkor lenne maximálisan foglalt, ha a 8-at közelíteni meg...

Megjegyzem, szerintem e terhelésből még jelentős mértékben le tudnék faragni, mert jelenleg a frissítési frekvencia másodpercenként 60-ra van állítva, ehhez képest viszont négyszer gyakrabban fut le a renderelő szál. Úgy vélem ez pocséklás, elég lenne azt fele gyakoriságúra korlátozni. Most azonban nem törődöm vele, előbb összehozom a text konzoljaimat, azután jönnek a sprite-ok.

Szegénykék, nem is tudjátok mit veszítetek, hogy nem ilyesmivel foglalkoztok... Komolyan, nincs is ÉLETETEK...

Hiszen mi más is az Élet lényege, ha nem az ALKOTÁS, a KREÁCIÓ?!

Olyankor érzi az Ember egy kicsit Istennek magát...

Programming is like using toilets; you can't say you are done until paperwork's finished!
Nyilvános megtekintési jogosultság letiltva.

Tervezzünk virtuális számítógépet! 2016 dec. 24 04:38 #2119

  • FossilCodger
  • FossilCodger profilkép
  • Nem elérhető
  • Arany fokozatú fórumozó
  • Hozzászólások: 201
  • Köszönetek: 6
  • Karma: 0
Na ennek nem nyitok külön topikot mert minek, úgyse olvassa senki... de ha mégis, na azzal közlöm hogy megoldódott életem egyik nagy problémája: Ma végre megérkezett a rendelt Tux-matrica amivel leragaszthattam a Windows-emblémát a billentyűzetemen! Egyszerűen okádhatnékom volt ha arra a gombra pillantottam.

Na most már ez NINCS. Leragasztottam a latop eredeti billentyűzetén is, meg a wireless billentyűzeten is. El se tudom mondani, mennyire másabb érzés ez így... Sokkal geekebb, bár ez nem is a legjobb szó arra amit érzek,.. Inkább arról van szó hogy most végre nem érzem úgy, hogy állandóan be akarna tolakodni az intim szoftveréletembe egy utálatos multi.

És van még három másik ilyen matricám tartaléknak...

Programming is like using toilets; you can't say you are done until paperwork's finished!
Nyilvános megtekintési jogosultság letiltva.
Az alábbi felhasználók mondtak köszönetet: attuska

Tervezzünk virtuális számítógépet! 2016 dec. 30 10:04 #2120

  • toroka
  • toroka profilkép
  • Nem elérhető
  • Adminisztrátor
  • Hozzászólások: 446
  • Köszönetek: 43
  • Karma: 8
Gratulálok! :)
Amúgy, boldog új évet kívánok neked és minden Linux Empire írónak és olvasónak!
Török Á.
Nyilvános megtekintési jogosultság letiltva.
Az alábbi felhasználók mondtak köszönetet: sanyimanó, FossilCodger
  • Oldal:
  • 1
  • 2
Oldalmegjelenítési idő: 0.143 másodperc