| Szerző |
Üzenet |
Chain-Q
Divatamigás
|
# Elküldve: 2014. Máj. 23. 08:27 - Szerkesztve: charlie
Ja és persze, van mégegy következménye ennek az ExtMem memória rendszernek - csak adatok kezelésére alkalmas, csakúgy mint az XMS-EMS, futtatható kód alapból nem tölthető be (hiszen az bármikor kilapozódhat, vagy kiugorhat a belapozott címterületből), 4GB fölött pedig képtelen futni, hiszen 32bites kód...
Természetesen megoldható - a saját kódod adatként való kezelésével - hogy saját magad kódot tölts erre a területre és aztán belapozd kézzel futtatás előtt, de ez még tovább bonyolítja az amúgy is elég specifikus és fájdalmasan favágó módszert. Mazochisták előnyben! :)
Szerk: Ha már az XMS/EMS vs. DPMI összehasonlításnál tartottunk, ez is egy nagy előnye volt az utóbbi módszernek - a memóriába egyszerre betöltött futtatható kód végre nagyobb lehetett mint 640K. Itt most erre megmarad a 2GB limit (ami figyelembe véve, hogy pl. az .so-k nem igazán "shared"-ek OS4-en, és minden alkalmazáshoz újra betöltődnek - és ebben az esetben nagyrészt kódról van szó - nem biztos hogy annyira vicces).
|
Lazi
Mr. AmiCon
|
# Elküldve: 2014. Máj. 23. 13:16 - Szerkesztve: lazi
A Ram Disk "felso" memoriaba tolasa mindenkeppen jo otlet. Ha majd mukodik is, azon latszik majd a teljesitmenye.
Sajnalom, ha a rendszerbe olyan megoldasok kerulnenek, amik a lehetsegesnel tobb kompromisszummal jarnak. Ezek egyertelmuen tavolabb viszik a rendszert attol amit Amiganak lehet megelni.
Ez egy igen komoly rendszerfelepitesi dontes, tehat remelem komolyan veszik.
Szerk: Egyebkent egyertelmuen adatrol ir a cikk, tehat kodnak nyilvan nem lesz jo.
|
Lazi
Mr. AmiCon
|
# Elküldve: 2014. Máj. 23. 13:35
Ha jol ertem, akkor ezzel a megoldassal ugyanugy elfogyhat a 32 bites cimterulet, ha tobb program is belapozgat maganak memoriat. Az ilyen ExtMem memoria foglalas sikeressegehez az kell, hogy legyen szabad cimterulet a 32 bites cimtartomanyban, vagyis kisebb meretu adatcsomagokat kell folyamatosan lapozgatni, hogy elkeruljuk az out of memory-t?
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 23. 13:56
En azt latom, hogy mar megint olyan dologgal foglalkozunk, ami nem igazan lenyeges!
Nem tudom, hogy OS4-en mi a helyzet (soha nem lattam OS4-et meg mukodni), de MOS-on egyaltalan nem szokott olyan elofordulni, hogy hirtelen elfogy a memoria. (Azt nem szamoljuk ide, amikor valami program elszabadul es felzabal mindent!) Esetleg olyankor, amikor a ramdisk-ben is van valami.
Abban viszont latnek fantaziat, hgy a RAM: kikeruljon a folos sok GB felso memoria teruletre, de allitolag az sem, olyan egyszeru!
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Máj. 23. 14:00 - Szerkesztve: charlie
@Lázi:
Az ilyen ExtMem memoria foglalas sikeressegehez az kell, hogy legyen szabad cimterulet a 32 bites cimtartomanyban, vagyis kisebb meretu adatcsomagokat kell folyamatosan lapozgatni, hogy elkeruljuk az out of memory-t?
Igen. Én legalábbis nem látok más lehetőséget. PC-n ugye adva volt, hogy max. 1 szegmenst (64K-t) lehet egyszerre látni, de mintha az EMS amúgy 16K-s adagokkal dolgozott volna... Jó rég volt szerencsére. Gondolom itt majd az MMU lapok méretének (4KByte???) többszöröse lesz, és lesz valami maximum korlát hozzá...
|
Lazi
Mr. AmiCon
|
# Elküldve: 2014. Máj. 23. 22:42 - Szerkesztve: lazi
Lehet, hogy elso lepeskent eleg lenne a ramdisk-et, illetve a vmem-et kiterjeszteni a 1.5Gb+ -ra. Mar az is ertelmes felhasznalasa lenne a tobblet memorianak. (legalabbis igy reszegen igy latom... :)
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 24. 05:56
Lazi:
Valaki a MorphZone-on irta, hogy MOS-on olyan se lesz, mert az se olyan egyszeru. De, en is igy latom!
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Máj. 24. 13:11
@Lázi:
Ezzel a megoldással az a baj, hogy nincs további lépés. Tehát anélkül amit már leírtam (egy tök független API, kódfuttatási lehetőséggel 2GB feletti memóriában és-vagy extra CPU-kon), nem lehet ezt a megoldást hova fejleszteni tovább. Viszont az ehhez szükséges megoldások - néhány egészen alapvető kernel MMU programozási kérdést leszámítva - gyakorlatilag függetlenek egymástól. Szóval ez nem első lépés, ez egy lépés egy olyan irányba, amerre nincs tovább, még ha az user szemszögéből ez annak is tűnik, hogy fúú, mennyivel közelebb kerültünk a jövőhöz.
Nem. Ez egy visszalépés és újra egy olyan API és már a bemutatása pillanatában elavult koncepcióra épülő alrendszer bevezetése, ami a jövőben végtelen számú helyen törheti el a Szent Kompatibilitást, ami miatt az egész hekkelés bevezetésre került.
Ez egy minden szempontból felesleges és rossz megoldás. End of story.
|
dh1
Mr. DTP
|
# Elküldve: 2014. Máj. 25. 10:02
En ezt az egeszet azert is tartom viccesnek, mert ugy csinalunk mintha ezen mulna a platform jovoje ...
Marmint van olyan progi keszuloben aminek nem eleg 1 giga ram?
He?
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 25. 15:04
dh1:
En is pont ezt kerdeztem... ;)
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Máj. 25. 15:23 - Szerkesztve: charlie
Igen, pont ez a problémám, hogy tök feleslegesen vezetnek be egy ilyen tákolmányt. Ez az egyik. A másik nyilván, hogy az A-Eonnak többezer eurót egy alaplapért kifizető ügyfelek akarják látni a Worbench címsorban a "8GB Extended Memory" feliratot, szóval ez a fícsör kb. erre jó, lehet mutogatni h. mennyi extended memorym van és lehet kínálni kb. 3db extra fizetős alkalmazást a már bejelentett állatkafa AmigaKit App Store-ban, ami majd valamire indokolatlanul használni is fogja, de minek...
|
dh1
Mr. DTP
|
# Elküldve: 2014. Máj. 25. 16:01
Ok, nem hasznaltok AEON hardvert, nem hasznaltok, OS4-et ... megis miert baj ez nektek?
Igen tudom, merthogy a szellemi tulajdon megint rosszaknal van (vannak egyaltalan jok? :)
Ott a jo kis MOS, ugy csuritek csavarjatok ahogy akarjatok, nem?!
Most oszinten csak az a baj, hogy nem AOS-nek hivjak?
Attol meg jo! Attol meg sok Amigas hasznalja mindkettot es nem veszik ossze onmagaval :)
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 26. 09:23 - Szerkesztve: dekanyz
Quoting: dh1 Ok, nem hasznaltok AEON hardvert, nem hasznaltok, OS4-et ... megis miert baj ez nektek?
Nem baj... Sot! ;)
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Júl. 29. 19:16 - Szerkesztve: charlie
Hyperion figyelő:
Ben Hermans megint ködösen ígérgetni kezdett, ezúttal ebben az AmigaWorld.net hozzászólásban. Szó van SMP-ről (vagy nem, mert hogy sokak szerint lehetetlen), az új hardware-eken és az OS4.2-n folyó munkáról, és mivel tudják hogy az userek már nagyon türelmetlenek, ezért "még az év vége előtt" (július van, mondanám én) egy jó kis meglepivel készülnek... Amiről persze nem derül ki bővebb infó.
Eközben a még mindig zászlóshajónak számító AmigaOne X1000 driverei odáig fejlődtek, hogy - röpke két és fél évvel azután, hogy az első felhasználók megkapták a gépeik - már hangerőt is lehet állítani az alaplapi chipsettel, mert működik a Mixer! Bővebben erről - és a fejlesztés közben felmerült technikai nehézségekről - a Hyperion blogjában írnak hosszasan.
|
AliveMOon
Tag
|
# Elküldve: 2014. Júl. 30. 00:50 - Szerkesztve: alivemoon
Aki lép halad, aki halad megérkezik egyszer :)
Már a Comi is megpróbálta több processzorosítani, nem tudni meddig jutottak, mert nem láttuk az eredményt.
Azt akarom mondani, ezt sem láttuk még, kíváncsian várom, mit alkotnak, ahelyett hogy kárognék :)
|
Lazi
Mr. AmiCon
|
# Elküldve: 2014. Júl. 30. 09:12
A 4.1 utan soron kovetkezo 4.2 nyilvan nem lenne meglepetes, szoval ez azt jelenti, iden nem lesz 4.2.
Huhh, akkor mar nem kell emiatt naponta ketszer az "Update Software" menut buzeralni. :)
|
dino
Kék troll
|
# Elküldve: 2014. Júl. 30. 09:29
Quoting: lazi A 4.1 utan soron kovetkezo 4.2 nyilvan nem lenne meglepetes, szoval ez azt jelenti, iden nem lesz 4.2.
Mekkora logikad van... :DD:DD
|
ratman
Kék troll
|
# Elküldve: 2014. Júl. 30. 19:56
Normális SMP-t nem lehet csinálni, AmigaOS-en. Illetve lehet, de hiába fog úgy kinézni, az nem lesz az, legalábbis a létező stuffok azonnal fejreállnak rajta, mert az exec akkor született, amikor még egy processzor bőven elég volt. :) Ajánlott olvasmány: ez, meg ez. Sajnos elég sok - amúgy rendszerbarát - stuff használja, meg elég sok komponens. Inkább csak annyit lehet elképzelni - de ilyet már láttunk is - hogy bizonyos taszkok más CPU-n futnak (ugye blizzardppc/cyberstormppc), ott meg ugye a cache-koherencia miatt elég lassú az állapottérváltás, amikor másik CPU-n futó tasznak kell futnia. Szerintem ez lesz az út, ami minimálisan elképzelhető, talán fognak tákolni is valamit, ami talán csinál is valamit, bár, ha úgy veszem, hogy több mint két(2!!!111) év kellett, hogy az alaplapi hang úgy működjön, ahogy elvárt az überfasza X1000-ben (meh), komoly kétségeim vannak. :)
Egyébként meg mint tudjuk, a hitet nem lehet megkérdőjelezni, mert azért hit.
|
AliveMOon
Tag
|
# Elküldve: 2014. Júl. 30. 20:21 - Szerkesztve: alivemoon
Speciel ezzel nem értek egyet, ha a programok használják rendesen a Permit/Forbid akkor faszán meg lehet csinálni.
Ezek függvények, API azaz mi van mögötte az exec-ben az rajta múlik.
Az tény, hogy újra kell tervezni, írni.
Ha én vónék a tervező, biztos úgy tervezném, hogy készítek egy vadi új exec-et és a régieknek szolgáltatna egy felületet, ami kiszolgálja őket.
Permit/Forbid-elhet a régi cucc de csak a régi API-t baszogatja.
Az újabb progik meg kapnak egy másik API-t.
Hasonló móka szerintem mint ahogy most futnak a 68K cuccok, csak most karanténba tenném a PPC32bit cumokat is.
Én úgy gondolom!
Végül is fügvény hívásokon, meg strukturákon keresztül érintkeznek a programok az OS-sel, azaz, az is jó, ha a libeken belül gyorsulnak fel, szépülnek meg avagy nőnek meg a dolgok, azzal is nyerhetnek a régi programok.
Alapvetően az a probléma, maguk a programok nem úgy lettek megírva, hogy 32bitnél nagyobb adatokat kezeljenek. Azaz azt nem is kell az OS-nek kijavítania!
Remélem ezt is csinálják!
Tényleg mondta valaki, hogy nem így csinálják?
Mert nekem úgy tűnik, arról a részről beszélnek, hogy a kompatibilitás hogyan marad meg!
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Júl. 31. 15:33 - Szerkesztve: charlie
@AliveMOon:
Speciel ezzel nem értek egyet, ha a programok használják rendesen a Permit/Forbid akkor faszán meg lehet csinálni.
Szerencsére nem azon múlik, hogy egyetértesz-e vele. A Ratman által leírt dolgok miatt elég lassú lenne egy ilyen, mivel Forbid()-nál a többi procin is meg kell állítani a taszkokat egyszerre... (Cacheflush, stb., többezer órajel, miközben 1 procin a Forbid() csak annyit csinál, hogy bebillent egy flaget az ütemezőben. Alsó hangon több ezerszeres lassulásról beszélünk a függvény kapcsán, hirtelen, egy olyan műveletben, amit egy aktív AmigaOS többszázszor csinál meg másodpercenként, még üresjáratban is.)
Permit/Forbid-elhet a régi cucc de csak a régi API-t baszogatja. Az újabb progik meg kapnak egy másik API-t.
Ja, de ekkor csak az újabb progik futhatnak at további magokon amivel két baj van.
1., Minden úgy van megírva, hogy Forbid()/Permit()-eljen, a rendszer nagyrésze maga is. Emiatt bármi, ami a további magokon fut, ha OS függvényt akar meghívni, annak át kell hívni az elsőszámú magra, amin lefut az OS függvény, aztán meg vissza... Jó gyors lesz ám ez. :)
2., Ez nem SMP, hanem aszimetrikus multiprocesszing, ami nyilván megcsinálható, lásd PowerUP és klónjai, az ugyanez, nagyjából... :)
Amúgy meg én nem értek hozzá, de Piru, aki írt vagy 3 AmigaOS kernelt élete alatt aszondta hogy visszafele kompatibilisen nem lehet valódi SMP-t csinálni (értsd: hagyományos Amiga programok egyszerre több magon futnak) és én inkább neki hiszek mint neked, vagy egy ügyvédnek. Bocs. De ha mégis nektek lesz igazatok, fizetek egy sört.
Egyébként az aszimmetrikus verziónak nyilván lenne értelme, még a hátrányaival együtt is, ezt senki nem vitatta, csakhogy nem ezt ígérik vagy jó régóta.
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Júl. 31. 15:43 - Szerkesztve: charlie
Hyperion figyelő, sokadik fejezet:
Ben Hermans a már hivatkozott szálban ismét megemlítette a 2001 óta hangoztatott FUD-ot, miszerint más AmigaOS "klónok" is az eredeti forrásra épülnek, illegálisan.
Ezután az userek kb. leoltották a picsába ahogy kell. Nem tudok mit hozzáfűzni.
|
ratman
Kék troll
|
# Elküldve: 2014. Júl. 31. 21:05
A véleményem ismert.
Valamint mint mindannyian tudjuk, hogy kevesen tudják, hogy meg vagyon ám írva, a Hyperion bukása. :D
|
AliveMOon
Tag
|
# Elküldve: 2014. Júl. 31. 21:46 - Szerkesztve: alivemoon
Én nem értem miért kéne egy új kernelben ugyanúgy működni a Permit/Forbid-nek, virtualizálni kell a régi API-t totális memoria védelembe zárni.
Permit/Forbid egy szándék a program részéröl, hogy a kernel csak vele foglalkozzon, de egy új virtualizáltabb környezetben ennek nem feltétlen kell így lennie.
A régi progikat belecsomagolni az egyébként új task rendszerbe.
A régi hívogatják a Permit/Forbid függvényt, aztán, hogy mit csinál vele az új kernel az már az ő saját magánügye.
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Aug. 01. 01:52
@AliveMOon:
Ha ez ilyen triviális, akkor ott az AROS kód, ugorj neki, ezek szerint csak bénaságból nem implementálják le mások vagy 20 éve. :P
virtualizálni kell a régi API-t totális memoria védelembe zárni.
Ezen meg különösen jót mosolygok, merthogy igen, erről szólt volna eredetileg a ... MorphOS... :) Hogy csinálnak egy classic Amiga sandboxot (ABox) és ezen kívül egy custom kernelre építve megcsinálnak egy újragondolt OS-t, új, modern API-kkal. Ezután az jött, hogy 15 éve hallgatjuk, hogy ez mekkora baromság, mert majd az OS4 megmutatja, hogy hogy is kell ezt és nem kell sandbox, fúj, fúj.
Mellékesen meg közben a MorphOS is leragadt a classic Amiga doboz fejlesztgetésénél, és egyelőre semmi sem lett a betervezett új rendszerből. Hát így.
|
AliveMOon
Tag
|
# Elküldve: 2014. Aug. 01. 07:24
Nem gondolom, hogy bénaságból, mást fontosabbnak tartottak.
Meg igazán vas sem volt, ahol SMP meg 64 bit lett volna!
Ha nem lenne az x1000 vagy Alma esély sem lenne több magos procival kisérletezni.
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Aug. 01. 08:25
@AliveMOon:
Az AROS fut x86-on ahol már 20 éve is voltak több procis rendszerek.
|
AliveMOon
Tag
|
# Elküldve: 2014. Aug. 01. 09:49 - Szerkesztve: alivemoon
UAE-ben is Permit/Forbid-olnak a programok és nem gyakja le se a Wint, sem az AmigaOS4-et, stb... :)
Tehát megvalósítható!
Ha kel pont legyen olyan szigorú a kernel, mintha emulátorban futtatná a taskot :)
|
smokey2k
Tag
|
# Elküldve: 2014. Aug. 01. 09:55
:)
no comment.... 20 év múlva is erről fogtok álmodozni.... észre kéne venni hogy ez a vonat technológiai években mérve már vagy 300 éve elment
egy raspberry-ben töb potenciál van mint bármilyen "nextgen" amiga rendszerben, de még hozzáteszem hogy akár egy c64-es bővítőkártyában is.
a jelenlegi amiga alapú rendszereknek egyáltalán nincs értelmes koncepciójuk vagy jövőképük.... amigások még ott tartanak hogy építsünk asztali pc-t ....őskor
|
dino
Kék troll
|
# Elküldve: 2014. Aug. 01. 13:03 - Szerkesztve: dino
Quoting: smokey2k egy raspberry-ben töb potenciál van mint bármilyen "nextgen" amiga rendszerben,
Aham, mire bebootol Amigan vagy (nextgen en) megirok egy mailt, es el is kuldom. :)
|
smokey2k
Tag
|
# Elküldve: 2014. Aug. 01. 14:01
dino ez most hogy jön ide ? vagy evvel most mit akartál mondani ?
kb mintha arról írtam volna hogy az ámbrás cet le tud merülni 2000 méter mélyre, te meg avval jössz hogy a 2-es golf-ból van diesel-es változat is :)
|
