Forum » Programiranje » [FASM] Kernel
[FASM] Kernel
DustWolf ::
Ko sem vidu ostale teme tu sem se sicer mal ustrašil ampak ajd, gremo probat vseeno.
Z 2mi kolegi smo se odločili napisat svoj Kernel in operacijski sistem v (F)ASM. Nič posebnega, nič velikega, načrtujemo 32bit, podporo za PXE boot in dostop do mreže, za grafiko samo VGA, datotečnega sistema pa ne bi imeli in bi bli pač vsi potrebni programi assemblani v sam boot binary. Edino načelo ki se ga res nameravamo držat je pa to da bi vso koda bila kjer bi bila z razlogom: nič ne bi bilo skopirano iz drugih OSov in vsak problem premišljen za to konkretno platformo. Namen je naredit mali hitri namenski OS z grafičnim vmesnikom za stare računalnike brez diskov in boot z mreže.
Ni kdovekako resen projekt z sponzorjem in končnim datumom... delamo ko se nam da in profita iz tega ni, razen kolikor se naučimo med potjo.
Iščem ljudi ki jih morda področje zanima in z katerimi bi lahko sodelovali. :) Ker trije ne vemo vsega, dokumentacijo pa je težko če ne nemogoče najt, je pomoč drugih geekov doborodošla.
LP,
Jure
Z 2mi kolegi smo se odločili napisat svoj Kernel in operacijski sistem v (F)ASM. Nič posebnega, nič velikega, načrtujemo 32bit, podporo za PXE boot in dostop do mreže, za grafiko samo VGA, datotečnega sistema pa ne bi imeli in bi bli pač vsi potrebni programi assemblani v sam boot binary. Edino načelo ki se ga res nameravamo držat je pa to da bi vso koda bila kjer bi bila z razlogom: nič ne bi bilo skopirano iz drugih OSov in vsak problem premišljen za to konkretno platformo. Namen je naredit mali hitri namenski OS z grafičnim vmesnikom za stare računalnike brez diskov in boot z mreže.
Ni kdovekako resen projekt z sponzorjem in končnim datumom... delamo ko se nam da in profita iz tega ni, razen kolikor se naučimo med potjo.
Iščem ljudi ki jih morda področje zanima in z katerimi bi lahko sodelovali. :) Ker trije ne vemo vsega, dokumentacijo pa je težko če ne nemogoče najt, je pomoč drugih geekov doborodošla.
LP,
Jure
Brane2 ::
BTW: Zakaj ne pokukate v Linux kernel za dokumentacijo ?
Koneckoncev je tudi v sami kodi marsikaj uporabnega...
Koneckoncev je tudi v sami kodi marsikaj uporabnega...
On the journey of life, I chose the psycho path.
DustWolf ::
Kukamo, kukamo.
Ampak v Linuxu je mariskaj narejeno na določen način brez kakega dobrega razloga... bolj kot nek fosil iz preteklosti. Naprimer če hočeš narest VGA implementacijo... pogledaš v Linux kodo in vidiš 95% kode je za prehod iz Linuxovega konzolnega načina pod pravim uporabnikom... Pogledaš po internetu najdeš kaka navodila kako se to piše, pa imaš zraven kup nekega preverjanja, ki ga v praksi sploh ne rabiš dodajat. Dissasemblaš Windowse in ugotoviš da prekleta stvar tudi nima prave implementacije ampak neprestano beži iz 32 protected v 16 bitni realmode, da lahko uporablja BIOSovo kodo. V glavnem, ni tako pregledno da bi lahko trdil na podlagi tistega da veš kaj točno rabiš naredit in česa ne.
Sicer pa ja, si pomagamo tud z takimi viri.
Ampak v Linuxu je mariskaj narejeno na določen način brez kakega dobrega razloga... bolj kot nek fosil iz preteklosti. Naprimer če hočeš narest VGA implementacijo... pogledaš v Linux kodo in vidiš 95% kode je za prehod iz Linuxovega konzolnega načina pod pravim uporabnikom... Pogledaš po internetu najdeš kaka navodila kako se to piše, pa imaš zraven kup nekega preverjanja, ki ga v praksi sploh ne rabiš dodajat. Dissasemblaš Windowse in ugotoviš da prekleta stvar tudi nima prave implementacije ampak neprestano beži iz 32 protected v 16 bitni realmode, da lahko uporablja BIOSovo kodo. V glavnem, ni tako pregledno da bi lahko trdil na podlagi tistega da veš kaj točno rabiš naredit in česa ne.
Sicer pa ja, si pomagamo tud z takimi viri.
Zgodovina sprememb…
- spremenil: DustWolf ()
Brane2 ::
Če se tako otepate fosilov, kaj sploh počnete z VGA ?
A ni enostavneje in predvsem bolj uporabno delat s framebufferjem skozi VESA specse ali kar direktno ?
Če se ne motim je vsaj za ATIja na voljo precej dokumentacije v to smer...
A ni enostavneje in predvsem bolj uporabno delat s framebufferjem skozi VESA specse ali kar direktno ?
Če se ne motim je vsaj za ATIja na voljo precej dokumentacije v to smer...
On the journey of life, I chose the psycho path.
DustWolf ::
No pač.. VESA / VGA... razlika v semantiki. V praksi itak ne počneš drugega kot to da pišeš v memory space, ker v 32bitnem načinu ne moreš uporabljat INT 10h. Kar se tiče fosilov pa... so VGA / VESA še zadnji standardi na tem področju. Za kaj več bi rabil pisat driverje za skoraj vsako kartico posebej. Z veseljem se lotim višjih resolucij, itd, ampak enostavno nimamo dovolj hardwarea za testiranje, pa tudi bolj ko kompliciraš manj dela.
Ali imaš morda link na ATIjevo VESA dokumentacijo?
Ali imaš morda link na ATIjevo VESA dokumentacijo?
Brane2 ::
Pri roki ne. Poglej si na Phoronix, tam je bilo nekaj objavljeno z linki.
Ampak če se ne motim, je VESA standarden in zanj rabiš docse z vesa.org
ATI je dal dokumentacijo za doslej zaprte stvari, torej low level register stuff...
Če se ne motim , zahteva tudi VESA 3.0 delo v realnem načinu in zato uporablja zanj linux v86d, ki omogoča emulacijo kode, ki jo je treba kao zagnati v real načinu, da skozi funkcijski klic flipneš register. v86d ni velik, a če ti je to odveč, zakaj ne narediš cele zadeve low level ?
Bog pomagaj, pač ne bo delala na HW celega planeta, so what ? Delala bo na tvojem HW in če bo to narejeno pametno, tudi prehod na drugi HW ne bo tako boleč, stvar bo pa optimizirana- kar je nekako cilj cele zadeve, če sem prav razumel.
BTW: Pod aktero licenco bo to - GPL ali kaj drugega ?
Ampak če se ne motim, je VESA standarden in zanj rabiš docse z vesa.org
ATI je dal dokumentacijo za doslej zaprte stvari, torej low level register stuff...
Če se ne motim , zahteva tudi VESA 3.0 delo v realnem načinu in zato uporablja zanj linux v86d, ki omogoča emulacijo kode, ki jo je treba kao zagnati v real načinu, da skozi funkcijski klic flipneš register. v86d ni velik, a če ti je to odveč, zakaj ne narediš cele zadeve low level ?
Bog pomagaj, pač ne bo delala na HW celega planeta, so what ? Delala bo na tvojem HW in če bo to narejeno pametno, tudi prehod na drugi HW ne bo tako boleč, stvar bo pa optimizirana- kar je nekako cilj cele zadeve, če sem prav razumel.
BTW: Pod aktero licenco bo to - GPL ali kaj drugega ?
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
Brane2 ::
In kako ste si zamislili celo zadevo ? Mislim, kako je z:
- multitasking
- multithreading
- SMP
- NUMA
- realtime schedulingom
- podporo userwareu ( GNU stuff ali kaj drugega ? )
- x86, x86_64, ARM, MIPS, tutti-frutti
- multitasking
- multithreading
- SMP
- NUMA
- realtime schedulingom
- podporo userwareu ( GNU stuff ali kaj drugega ? )
- x86, x86_64, ARM, MIPS, tutti-frutti
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
DustWolf ::
PDFji iz vesa.org so pisani za proizvajalce grafičnih kartic in so kot taki za programerje povsem neuporabni. Bom pogledal po ATIjevi spletni... upam da je po prenovi še kaj ostalo od tega kar opisuješ.
To da bi blo treba registre flippat skozi realmode.. tega še nisem nikjer zasledil, ampak če bo res potrebno... bomo že. Kaj si mislil s tem da bi "celo zadevo naredil v low level"? V realmode? Zakaj če sem kernel?
Cilj je sicer da bi bila stvar "optimizirana"... v bistvu bolj "pravilno napisana" kot "naknadno optimizirana" ampak ja. Če veš kaj delaš lahko napišeš bolje.
To da bi blo treba registre flippat skozi realmode.. tega še nisem nikjer zasledil, ampak če bo res potrebno... bomo že. Kaj si mislil s tem da bi "celo zadevo naredil v low level"? V realmode? Zakaj če sem kernel?
Cilj je sicer da bi bila stvar "optimizirana"... v bistvu bolj "pravilno napisana" kot "naknadno optimizirana" ampak ja. Če veš kaj delaš lahko napišeš bolje.
DustWolf ::
In kako ste si zamislili celo zadevo ? Mislim, kako je z:
- multitasking
- multithreading
- SMP
- NUMA
- realtime schedulingom
- podporo userwareu ( GNU stuff ali kaj drugega ? )
- x86, x86_64, ARM, MIPS, tutti-frutti
32bit i386+.
V planu... zdaj je to pač plan kot teorija zato ker niti flip v 32bit mode še ni napisan pravilno (ker smo prej pisali za x64 ki je brez segmentationa bistveno manjši glavobol potem pa smo se premislili).
Torej v planu je da blo strukturirano v okvirje ... se pravi kernel je root aplikacija, ta potem znotraj nje poganja več programov, in ti znotraj njih poganjajo še več programov ki bi komunicirali z temi programi misleč da so oni kernel... v glavnem neka taka Event driven struktura, v kateri je vsak program lahko VM za druge programe. V praksi to zgleda zelo enostavno, ISR obdela in posreduje klic z podatki ISRju znotraj njega, tak da se ISR nadaljuje dokler ne pride do tistih programov ki so najbolj noter in dobijo končni podatek. Tudi pisanje vmesnikov je zaradi tega simple, ker vsaka lupina implementira vse kar programje noter potrebuje in ni kompliciranja. To idejo je seveda treba probat, če se bo izšla v praksi (npr.: kaj se zgodi ko se začne preveč ISRjev preden se prvi konča), itd, ampak probali pa vseeno bi.
Seveda pa to tudi pomeni da GNU programi odpadejo, ker ne delujejo po tem principu... razen če se potem pojavi kak način. Poanta je vendarle naredit OS (se pravi tudi aplikacije), ki omogočajo nekaj osnovnega kar pričakuješ od stare šare. Napisat browser bi sicer lahko bil glavobol ampak.. pustimo to, ni bistveno.
Brane2 ::
To da bi blo treba registre flippat skozi realmode.. tega še nisem nikjer zasledil, ampak če bo res potrebno... bomo že.
Čisto možno,d a se motim. Kot mi je bilo razloženo, je to razlog, zakaj uvesafb driver potrebuje v86d...
Kaj si mislil s tem da bi "celo zadevo naredil v low level"? V realmode? Zakaj če sem kernel?
Mislil sem, zakaj se opirati na nek VESA, če to pomeni glavobole, če pa lahko flipneš par bitov v nekem registru kar sam ročno za to, da postaviš npr pravo bitno globino in ločljivost.
Cilj je sicer da bi bila stvar "optimizirana"... v bistvu bolj "pravilno napisana" kot "naknadno optimizirana" ampak ja. Če veš kaj delaš lahko napišeš bolje.
Ja, če gre za kak kratek, optimiziran program. Ampak tole je kernel, hudiča. Par maljonov vrstic C kode. Tudi če je mnogo fosilized crapa notri, še vedno ostane ogromno.
Pa neki niti ni tako slaba koda not. Kot sem videl, večinoma streamlined, no-nonsense C, ob dodanem asmju tam kjer je treba.
A ne bi blo lažje začet z vanilla-kernelom in tega oklestit na to, kar rabiš in prešaltat na C kot default ob asm overrideu za stvari, ki zahtevajo personal touch ?
Linux kernel vmesnik se ne zdi napačen za moderen današnji stroj z MMU protectionom in različnimi execution privilege leveli.
Če je sprejemljiv, zakaj ga ne bi obdržal in tako dobil kup userlandea, ki bi ga lahko ponucal vsaj na začetku ?
Poleg tega je vprašljivo, koliko bo stvar res optimizirana, če ti je najnižji skupni imenovalec res i386.
Mislim, saj z ročnim pisanjem asm res lahko nekaj pridobiš, ampak tu je očitno, da tudi nekaj izgubiš. Očitno nimaš dovolj rok, da bi na enak način pokril tudi i{4,5,6...}86 in x86_64.
Zanimivo bi se bilo igrati s "popravljenim" Linux kernelom z recimo totalka prenovljenim video driverjem, kjer bi imel namesto tiste trapaste terminal emulacije konsolo, ki bi že v "tekstualnem načinu" delala z z vektorskimi fonti, imela po defaultu pospešen framebuffer in OpenGl. Ali recimo definiran in standardiziran kernel vmesnik, kamor bi lahko aplikacije priklapljale svoje module in bi tako en, CPU intenziven, od zunanjih dogodkov odvisen in asinhron del aplikacije lahko laufal neposredno brez preklopa kernel--userspace.
Ali kaj petega.
On the journey of life, I chose the psycho path.
DustWolf ::
Čisto možno,d a se motim. Kot mi je bilo razloženo, je to razlog, zakaj uvesafb driver potrebuje v86d...
Verjetno za isti namen kot Windowsi... poganjaš BIOSovo kodo, ki je že napisana specifično za vsak hardware, ker se ob bootu fizično sname z kartice. Pač malo muke da spraviš v delovanje ampak zato vedno dela. V bistvu so mi predlagali ta pristop že na začetku na FASM forumu, ampak ko sem videl kakšen je vmesnik sem se odločil da bom raje vzel VESA način.
Mislil sem, zakaj se opirati na nek VESA, če to pomeni glavobole, če pa lahko flipneš par bitov v nekem registru kar sam ročno za to, da postaviš npr pravo bitno globino in ločljivost.
V bistvu počnem točno to. Memorija vsebuje samo vsebino zaslona (kaj odvisno od tega ali želiš tekstovni ali grafični način, potem pa so še finte), tiste bite pa se premika z in/out ukazi, da dosežeš pravi mode. To je VESA. Finta je bolj v tem kateri bit premaknit kam -- namreč jaz sem naredil po dokumentaciji pa se nič ne dogaja in ne vem več kaj naj naredim. ;)
Ja, če gre za kak kratek, optimiziran program. Ampak tole je kernel, hudiča. Par maljonov vrstic C kode. Tudi če je mnogo fosilized crapa notri, še vedno ostane ogromno.
Glej... moraš razumet da samo zato ker je Linux 300 MB sourca da še ne pomeni da mora biti čisto vsak kernel tak bloat. Ne trdim da je v Linuxu kaj narobe ampak Linux je makrokernel... To je kernel ki vsebuje dobesedno vse. Še Windows je nek hibridni kernel, ki je v bistvu razmeroma velik (v praksi tako majhen da večina stručkotov ne ve v kerem fajlu se skriva)... jaz planiram mikrokernel, se pravi minimalni set funkcij, gonilnikov ni, itd, toliko da dela tisto kar jaz rabim. V praksi to ni veliko kode.
Takole eno izobraženo ugibanje, tudi če vzameš nek enostavni boot loader (moj trenutni je 72 ukazov), GDT in potrebne strukture kot memory managment, hookneš timer ISR za CPU Scheduling in morda še par funkcij v kernelu za lažje programiranje... prideš recimo nekje na 400 ukazov, kar v praksi ni nič (nekje 2 kb boot image, odvisno koliko praznega prostora imaš med bloki), je to že kernel. Ni nevemkaj ampak je kernel.
Pa neki niti ni tako slaba koda not. Kot sem videl, večinoma streamlined, no-nonsense C, ob dodanem asmju tam kjer je treba.
A ne bi blo lažje začet z vanilla-kernelom in tega oklestit na to, kar rabiš in prešaltat na C kot default ob asm overrideu za stvari, ki zahtevajo personal touch ?
In v čem bi bil potem pojnt pisanja kernela? Še enega Linuxa ne rabim, mi je čisto všeč Ubuntu (v bistvu brez Linuxa mojega kernela še bootat ne bo šlo, ker rabi BOOTP server). Hočem pa svoj kernel, da se naučim kernele pisat, in da probam (ker koliko vidim, ni prav veliko ljudi na svetu ki so to probali) in pa zato da (si) dokažem da so moje ideje dobre ali slabe.
Linux kernel vmesnik se ne zdi napačen za moderen današnji stroj z MMU protectionom in različnimi execution privilege leveli.
Če je sprejemljiv, zakaj ga ne bi obdržal in tako dobil kup userlandea, ki bi ga lahko ponucal vsaj na začetku ?
Memory managment in execution levelje (ringe) obvladam sam čisto vredu, hvala lepa. Vem da ima Intel arhitekutra zelo nadležna ampak potem ko enkrat znaš ni nemogoče ali nevemkako težko. Težko oziroma nemogoče je samo ugibanje na začetku ko nimaš dobre dokumentacije.
Poleg tega je vprašljivo, koliko bo stvar res optimizirana, če ti je najnižji skupni imenovalec res i386.
Mislim, saj z ročnim pisanjem asm res lahko nekaj pridobiš, ampak tu je očitno, da tudi nekaj izgubiš. Očitno nimaš dovolj rok, da bi na enak način pokril tudi i{4,5,6...}86 in x86_64.
Nima smisla da bi, ker planiram da bom reč uporabljal na stari šari, kar so i386 računalniki. Seveda smo prej pomislili na x86_64, ki je programiranju dosti bolj prijazen, ampak potem pogruntaš da stvari nimaš kje testirat kaj šele uporabljat.
Se pa z tvojo oceno da je ASM tu brezveze uporabljat ne morem strinjati... pač... ko stvar vidiš pod pokrovom kaj hardware zares potrebuje in kaj mu ti compilerji futrajo... ne rečem da so compilerji zanič (čeprav je to verjetno res), ampak enostavno ko ti kodo vpišeš v compiler to počneš zato ker se ti ne da vnašati določenih podrobnosti, ampak to se na koncu pozna. Compiler ne more uganit kaj si poizkušal narest in izpolnit manjkajoče z lastno iznajdljivostjo ker je pač nima. Če pa ti veš kaj delaš ko pišeš ASM lahko nekaj napišeš tako da naredi točno tisto kar ti rabiš in nič drugega in potem dela bolje. To morda ne velja za programje znotraj Windowsov, itd, ampak v kernelu je pa to bistveno.
C je smiselen tam kjer hočeš uporabit komponente ki so jih drugi že napisali, pri kernelu tega nočeš, pri kernelu hočeš napisat tisto kar si imel ti v mislih, ne kdo drug, zato da lahko poizkusiš implementacijo boljše ideje.
Zanimivo bi se bilo igrati s "popravljenim" Linux kernelom z recimo totalka prenovljenim video driverjem, kjer bi imel namesto tiste trapaste terminal emulacije konsolo, ki bi že v "tekstualnem načinu" delala z z vektorskimi fonti, imela po defaultu pospešen framebuffer in OpenGl. Ali recimo definiran in standardiziran kernel vmesnik, kamor bi lahko aplikacije priklapljale svoje module in bi tako en, CPU intenziven, od zunanjih dogodkov odvisen in asinhron del aplikacije lahko laufal neposredno brez preklopa kernel--userspace.
Ali kaj petega.
Ti ne branim, kar naredi. ;) Samo se mi zdi da boš opazil da je tesktovni način takšen kot je zato ker je platforma z 8x8 boxi za črke implementirana v hardwareu, OpenGL je pa samo softwerska knjižnjica. Za preklapljanje kernel--userspace si pa poglej kernelove module (ni čisto na istem ringu kot kernel) ali pa windows gonilike (ring 0).
LP
Tukaj se strinjam z Branetom. Resno mislite, da je ASM prava resitev? Nevem no.
Boš ti naredil boot loader pa preklop v 32bit protected mode v Cju?
Be my guest. :)
Zgodovina sprememb…
- spremenil: DustWolf ()
Brane2 ::
Ne mislim se kregat, le sprašujem.
Ne štekam, kaj dobiš s tem. O.K. driverje daš izven kernela, a s tem ne izginejo. Še vedno jih rabiš, tokrat izven kernela.
Fino. Ampak teh 400 ukazov verejtno nisi spravil skupaj v pol ure. Sedaj oceni še količino kode, ki jo rabiš za driverje in userland in oceni koliko časa ti bo vzelo pisanje te kode...
V tweakingu off-the-shelf robe za svoje namene. Hočem samo reči naslednje - tudi če predpostavimo, da si sposoben pisat _idealno_ asm kodo, je tu še vedno hitrostni davek-čas, ki ga rabiš za pesnitev. od trenutka, ko si se lotil zadeve, do trenutka konca projekta zna preteči toliko časa, da se bo celo HW drastično spremenil. Nič ti ne pomaga hudo optimizirana koda, če se v sredi projekta _tarča_ spremeni in se sedaj vsi usmerite na recimo ARM, MIPS ali kaj sedmega. Pravzaprav bi bil že prehod 386-Pentium dovolj velik glavobol.
V bistvu se implementacije razlikujejo - od 8x8 do 16x22 alkolkže in vse vmes. Če teh HW zahtev ni več, te tudi SW sam zase ne veže na nek sveti format.
Da ni ? Sem mislil da tako Lin kot Win uporablajta isti način Ring 0 za kernel in Ring 3 za userland.
Hočeš reči, da se modul linka bistveno različno, če ga compileaš in-kernel oziroma kot discrete-module ?
Sem mislil, da je edina razlika možnost rezervacije pomnilnika...
Glej... moraš razumet da samo zato ker je Linux 300 MB sourca da še ne pomeni da mora biti čisto vsak kernel tak bloat. Ne trdim da je v Linuxu kaj narobe ampak Linux je makrokernel... To je kernel ki vsebuje dobesedno vse. Še Windows je nek hibridni kernel, ki je v bistvu razmeroma velik (v praksi tako majhen da večina stručkotov ne ve v kerem fajlu se skriva)... jaz planiram mikrokernel, se pravi minimalni set funkcij, gonilnikov ni, itd, toliko da dela tisto kar jaz rabim. V praksi to ni veliko kode.
Ne štekam, kaj dobiš s tem. O.K. driverje daš izven kernela, a s tem ne izginejo. Še vedno jih rabiš, tokrat izven kernela.
Takole eno izobraženo ugibanje, tudi če vzameš nek enostavni boot loader (moj trenutni je 72 ukazov), GDT in potrebne strukture kot memory managment, hookneš timer ISR za CPU Scheduling in morda še par funkcij v kernelu za lažje programiranje... prideš recimo nekje na 400 ukazov, kar v praksi ni nič (nekje 2 kb boot image, odvisno koliko praznega prostora imaš med bloki), je to že kernel. Ni nevemkaj ampak je kernel.
Fino. Ampak teh 400 ukazov verejtno nisi spravil skupaj v pol ure. Sedaj oceni še količino kode, ki jo rabiš za driverje in userland in oceni koliko časa ti bo vzelo pisanje te kode...
In v čem bi bil potem pojnt pisanja kernela?
V tweakingu off-the-shelf robe za svoje namene. Hočem samo reči naslednje - tudi če predpostavimo, da si sposoben pisat _idealno_ asm kodo, je tu še vedno hitrostni davek-čas, ki ga rabiš za pesnitev. od trenutka, ko si se lotil zadeve, do trenutka konca projekta zna preteči toliko časa, da se bo celo HW drastično spremenil. Nič ti ne pomaga hudo optimizirana koda, če se v sredi projekta _tarča_ spremeni in se sedaj vsi usmerite na recimo ARM, MIPS ali kaj sedmega. Pravzaprav bi bil že prehod 386-Pentium dovolj velik glavobol.
Ti ne branim, kar naredi. ;) Samo se mi zdi da boš opazil da je tesktovni način takšen kot je zato ker je platforma z 8x8 boxi za črke implementirana v hardwareu,
V bistvu se implementacije razlikujejo - od 8x8 do 16x22 alkolkže in vse vmes. Če teh HW zahtev ni več, te tudi SW sam zase ne veže na nek sveti format.
OpenGL je pa samo softwerska knjižnjica. Za preklapljanje kernel--userspace si pa poglej kernelove module (ni čisto na istem ringu kot kernel) ali pa windows gonilike (ring 0).
Da ni ? Sem mislil da tako Lin kot Win uporablajta isti način Ring 0 za kernel in Ring 3 za userland.
Hočeš reči, da se modul linka bistveno različno, če ga compileaš in-kernel oziroma kot discrete-module ?
Sem mislil, da je edina razlika možnost rezervacije pomnilnika...
On the journey of life, I chose the psycho path.
Brane2 ::
Boš ti naredil boot loader pa preklop v 32bit protected mode v Cju?
Be my guest. :)
Pa saj tudi v linux kernelu to ni napisano v Cju. Zadeva je AFAIK pod arch-specific mapi izvedena v asm.
Kje je problem ?
On the journey of life, I chose the psycho path.
BigWhale ::
Tukaj se strinjam z Branetom. Resno mislite, da je ASM prava resitev? Nevem no.
Boš ti naredil boot loader pa preklop v 32bit protected mode v Cju?
Be my guest. :)
Jaz sem razumel, da boste komplet kernel spisali v ASM.
Brane2 ::
Kaj se bo zgodilo, ko bo nekdo sredi projekta ugotovil, da i386 ni več optimalni stroj, ker so tudi najcenejši mikrokrmilniki v bistvu i486 stroji ?
Čeprav je -486 upwards-compatible, pa to ni v performance-optimised kernelu. Instruction scheduling se spremeni, ravno tako kojekakvi alignmenti in timingi.
Pa recimo, da zberete voljo in čas in prečešete ves source še enkrat in dobite 486-optimised verzijo.
Kako dalje ? Boste furali in razvijali ločeno i386 in i486 ali bo vedno le ena verzija v igri ?
BTW:
Kakšne veze ima bootloader length z vsem ? Who cares, pa če zavzame tudi megabajt zaradi mene.
Saj ta RAM se po opravljenem bootloadanju sprosti, a se ne ?
Čeprav je -486 upwards-compatible, pa to ni v performance-optimised kernelu. Instruction scheduling se spremeni, ravno tako kojekakvi alignmenti in timingi.
Pa recimo, da zberete voljo in čas in prečešete ves source še enkrat in dobite 486-optimised verzijo.
Kako dalje ? Boste furali in razvijali ločeno i386 in i486 ali bo vedno le ena verzija v igri ?
BTW:
Kakšne veze ima bootloader length z vsem ? Who cares, pa če zavzame tudi megabajt zaradi mene.
Saj ta RAM se po opravljenem bootloadanju sprosti, a se ne ?
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
DustWolf ::
Da se razumemo, jaz se ne kregam. :) Samo poizkušam razložit stvar da bi pritegnil koga k sodelovanju.
Preveč sproti bereš wikipedijo pa premalo se posvečaš mojemu pisanju za to debato.. :D Jaz ne nameravam pisat gonilnikov. V kernelu bo osnovna funkcijonalnost za grafični način in.. nevem.. bom videl, nek input. Tipkovnico verjetno, morda miš. Z drugimi besedami, nič kaj dosti.
Mislim da še vedno nimaš pravega koncepta v glavi... jaz ne nameravam komplicirat z kodo. Kompliciranje ni namen. To pomeni da odpadejo, gonilniki, nek bajen userland, itd. Za učenje pisanja kernela mi pa ni škoda časa ker je to namen.
Si že kdaj pisal ASM kodo? Izven faksa?
Ne govorim o optimizaciji ki jo lahko dobiš iz površnega branja knjig o tem. Ne nameravam premetavati ukazov v kodi da bom lovil pipeline. To ni namen in nima smisla. Kernel ni računalniška igrica, da bi potreboval optimizacijo na FPU. Izvorni greh počasnih operacijskih sistemov je v tem da so slabo zastavljeni. Na kernel levelu so celo 200 MHz računalniki nepredstavljivo hitri, vse se zgodi v trenutku... dokler ne dodaš kode ki vse skupaj upočasnjuje. Če to kodo napišeš tako da je izguba minimalna, vseeno pa imaš funkcionalnost za katero veš da jo rabiš, potem je OS hiter. V tem je optimizacja, zato je ASM. Da napišeš kar rabiš, kjer rabiš, brez priveskov od compilerja in kroženja okrog vroče sklede kjer bi lahko nekaj implementiral neposredno, pa se ne da zaradi jezika.
Ja.. Text mode podpira spreminjajnje teh definicij. Ampak poanta text moda je v tem da je pripravljen na uporabo pri bootu, takoj. Za debug in brez odvečne kode. V Text modu enostavno dumpaš ASCII tekst v mapiran video ram v osrednjem ramu in že je na ekranu. Saj lahko fonte spremeniš, flipneš register in jih pustiš v mapiranem video ramu.
Ko sem jaz pisal boot loader za naš kernel, sem ugotovil kako zelo uporabno je če imaš nek izhod kamor lahko butneš debugging podatke in se zanesljivo prikažejo. To je ta sveti format. :)
Hm. Windowsi so bili v originalu napisani za Alpha arhitekturo ki ima samo dva ringa in potem ko so bili portani je seveda iz tega nastal ring 0 in ring 3. Za Linux, kolikor vem to ne velja... no seveda je na ring0 kernel in na ring3 usermode ampak, kernel moduli so pa na ring1, kolikor vem.
Kot ring1 je kernel modul še vedno priviligiran nad usermodom, ampak ne more pa sesuti kernela, naprimer.
Ne bom trdil zagotovo.. ampak tako sem videl ko sem bral po izvorni kodi, logih, itd.
Ne štekam, kaj dobiš s tem. O.K. driverje daš izven kernela, a s tem ne izginejo. Še vedno jih rabiš, tokrat izven kernela.
Preveč sproti bereš wikipedijo pa premalo se posvečaš mojemu pisanju za to debato.. :D Jaz ne nameravam pisat gonilnikov. V kernelu bo osnovna funkcijonalnost za grafični način in.. nevem.. bom videl, nek input. Tipkovnico verjetno, morda miš. Z drugimi besedami, nič kaj dosti.
Fino. Ampak teh 400 ukazov verejtno nisi spravil skupaj v pol ure. Sedaj oceni še količino kode, ki jo rabiš za driverje in userland in oceni koliko časa ti bo vzelo pisanje te kode...
Mislim da še vedno nimaš pravega koncepta v glavi... jaz ne nameravam komplicirat z kodo. Kompliciranje ni namen. To pomeni da odpadejo, gonilniki, nek bajen userland, itd. Za učenje pisanja kernela mi pa ni škoda časa ker je to namen.
V tweakingu off-the-shelf robe za svoje namene. Hočem samo reči naslednje - tudi če predpostavimo, da si sposoben pisat _idealno_ asm kodo, je tu še vedno hitrostni davek-čas, ki ga rabiš za pesnitev. od trenutka, ko si se lotil zadeve, do trenutka konca projekta zna preteči toliko časa, da se bo celo HW drastično spremenil. Nič ti ne pomaga hudo optimizirana koda, če se v sredi projekta _tarča_ spremeni in se sedaj vsi usmerite na recimo ARM, MIPS ali kaj sedmega. Pravzaprav bi bil že prehod 386-Pentium dovolj velik glavobol.
Si že kdaj pisal ASM kodo? Izven faksa?
Ne govorim o optimizaciji ki jo lahko dobiš iz površnega branja knjig o tem. Ne nameravam premetavati ukazov v kodi da bom lovil pipeline. To ni namen in nima smisla. Kernel ni računalniška igrica, da bi potreboval optimizacijo na FPU. Izvorni greh počasnih operacijskih sistemov je v tem da so slabo zastavljeni. Na kernel levelu so celo 200 MHz računalniki nepredstavljivo hitri, vse se zgodi v trenutku... dokler ne dodaš kode ki vse skupaj upočasnjuje. Če to kodo napišeš tako da je izguba minimalna, vseeno pa imaš funkcionalnost za katero veš da jo rabiš, potem je OS hiter. V tem je optimizacja, zato je ASM. Da napišeš kar rabiš, kjer rabiš, brez priveskov od compilerja in kroženja okrog vroče sklede kjer bi lahko nekaj implementiral neposredno, pa se ne da zaradi jezika.
V bistvu se implementacije razlikujejo - od 8x8 do 16x22 alkolkže in vse vmes. Če teh HW zahtev ni več, te tudi SW sam zase ne veže na nek sveti format.
Ja.. Text mode podpira spreminjajnje teh definicij. Ampak poanta text moda je v tem da je pripravljen na uporabo pri bootu, takoj. Za debug in brez odvečne kode. V Text modu enostavno dumpaš ASCII tekst v mapiran video ram v osrednjem ramu in že je na ekranu. Saj lahko fonte spremeniš, flipneš register in jih pustiš v mapiranem video ramu.
Ko sem jaz pisal boot loader za naš kernel, sem ugotovil kako zelo uporabno je če imaš nek izhod kamor lahko butneš debugging podatke in se zanesljivo prikažejo. To je ta sveti format. :)
Da ni ? Sem mislil da tako Lin kot Win uporablajta isti način Ring 0 za kernel in Ring 3 za userland.
Hm. Windowsi so bili v originalu napisani za Alpha arhitekturo ki ima samo dva ringa in potem ko so bili portani je seveda iz tega nastal ring 0 in ring 3. Za Linux, kolikor vem to ne velja... no seveda je na ring0 kernel in na ring3 usermode ampak, kernel moduli so pa na ring1, kolikor vem.
Hočeš reči, da se modul linka bistveno različno, če ga compileaš in-kernel oziroma kot discrete-module ?
Sem mislil, da je edina razlika možnost rezervacije pomnilnika...
Kot ring1 je kernel modul še vedno priviligiran nad usermodom, ampak ne more pa sesuti kernela, naprimer.
Ne bom trdil zagotovo.. ampak tako sem videl ko sem bral po izvorni kodi, logih, itd.
Mavrik ::
Bodo pa šli pisat na novo. Saj jim ni cilj narediti drugega linuxa, kot je tip napisal jim je cilj se naučiti low-level delovanja sistema s tem da spišejo nek osnovni OS. V čem je smisel tega tvojega teženja za nečim brezveze zakompliciranim, ki se ne sklada z njihovimi cilji?
The truth is rarely pure and never simple.
Brane2 ::
Preveč sproti bereš wikipedijo pa premalo se posvečaš mojemu pisanju za to debato.. :D Jaz ne nameravam pisat gonilnikov. V kernelu bo osnovna funkcijonalnost za grafični način in.. nevem.. bom videl, nek input. Tipkovnico verjetno, morda miš. Z drugimi besedami, nič kaj dosti.
ČE je predvidena funkcija te zadeve simpl grafični terminal, fajn. Če ni in bi rad vsaj nek tekst editor pa mogoče vsaj simpl browser, so problemi. Saj je kar nekaj kode zunaj za te zadeve, a mislim da ne na ta način- pisane v hand-optimised asm.
Če pa se spustiš še v pisanje tega, potem pa stvari sploh ne bodo več tako zelo minimalne.
Mislim da še vedno nimaš pravega koncepta v glavi... jaz ne nameravam komplicirat z kodo. Kompliciranje ni namen. To pomeni da odpadejo, gonilniki, nek bajen userland, itd. Za učenje pisanja kernela mi pa ni škoda časa ker je to namen.
O.K. Ampak če sem prav dojel, to kar bi rrad izpeljal, boš lažje naredil na nekem simpl mikrokrmilniku. Nekaj v smislu Atmelovega AVR, mogoče v tamočni izvedenki ali kakim ARMom ali čem podobnim. Resda ni zasnovan na prejšnjih genereacijah CPUjev, je pa full poceni, majhen in _zelo_ malo porabi.
Si že kdaj pisal ASM kodo? Izven faksa?
Faks nisem dokončal, pa tudi kaj dosti kode nismo obdelali tam ta čas. Sem se pa doma izživljal na osembitnih mlinčkih, šestnajstbitnih (QL_MC68008, Atari ST -68000 ), mikrokrmilnikih ( 80xx, PIC) in podobnih zadevah, sedaj pa se hecam z i86/x86_64.
Ne govorim o optimizaciji ki jo lahko dobiš iz površnega branja knjig o tem. Ne nameravam premetavati ukazov v kodi da bom lovil pipeline. To ni namen in nima smisla. Kernel ni računalniška igrica, da bi potreboval optimizacijo na FPU. Izvorni greh počasnih operacijskih sistemov je v tem da so slabo zastavljeni. Na kernel levelu so celo 200 MHz računalniki nepredstavljivo hitri, vse se zgodi v trenutku... dokler ne dodaš kode ki vse skupaj upočasnjuje.
O.K. Kje recimo linux kernel izgublja tako veliko časa, da bi se to splačalo ? Saj ne rečem,d a ga ne- koneckoncev obstaja kup alternativnih projektov, ampak kej je to tako izrazito, da to lahko pokažeš s prstom tako iz letala in pri tem oceniš "škodo", ki jo uporabnik trpi zaradi tega ?
Ravno te dni se hecam nekaj s kodo za izračunavanje P/Q paritete za RAID-5/6 polja in je na Linuxu napisana kar fino. Toliko, da težko najdem bistven plac za izboljšavo- v asm.
kar pa se ostalega "bloata" tiče- hja nekdo ga je zahteval in tudi dobil - ker je Linus mislil, da je to lahko za nekoga dobra ideja.
Sploh pa, koliko časa preživijo aplikacije dejanjsko v kernelu ?
Ta dobi zahtevo in jo obdela- v veliki večini gre za zahteve nekim napravam, task scheduling in irq response.
Če to kodo napišeš tako da je izguba minimalna, vseeno pa imaš funkcionalnost za katero veš da jo rabiš, potem je OS hiter. V tem je optimizacja, zato je ASM. Da napišeš kar rabiš, kjer rabiš, brez priveskov od compilerja in kroženja okrog vroče sklede kjer bi lahko nekaj implementiral neposredno, pa se ne da zaradi jezika.
Pa saj compiler ti omogoča skok v asm kadarkoli ti to zapaše sredi samega sourcea. Sam pri (resda bežni) analizi v običajnih fileih nisem zapazil nekega strašnega razmetavanja z resursi. Tam, kjer pa compiler bistveno fali, pač stvari popraviš ročno...
Ja.. Text mode podpira spreminjajnje teh definicij. Ampak poanta text moda je v tem da je pripravljen na uporabo pri bootu, takoj.
Tu je sploh ni. Poanta je bila nekoč, ko so bile neke kartice še čisto tekstualne in ti je VGA ponujala varen default.
Ali ko so bile prve implementacije framebuferja skarjno blesave in si vanj videl po straneh od 16KB.
Ves tovrstno blesav hardver je že davno izven uporabe, in praktično vse ti ponuja framebuffer. Zakaj bi se torej še zaj* s tekstualnim modom ?
Za debug in brez odvečne kode. V Text modu enostavno dumpaš ASCII tekst v mapiran video ram v osrednjem ramu in že je na ekranu. Saj lahko fonte spremeniš, flipneš register in jih pustiš v mapiranem video ramu.
Ja, vpis enega namesto osmih byteov pa res drastično spremeni stvari, sploh ob pametni organizaciji podatkov in upoštevanju filanja cachelineov- ko si dosegel prvi byte, so naslednji 3-je v istem registru in naslednji 4-12 že praktično v cachelineu...
Pa ta izvedba ti tudi poenostavi delo za zaslonom - vse vidiš kot grafiko.
Ko sem jaz pisal boot loader za naš kernel, sem ugotovil kako zelo uporabno je če imaš nek izhod kamor lahko butneš debugging podatke in se zanesljivo prikažejo. To je ta sveti format. :)
AFAIK lin kernel uporablja za te zadeve serial line in tudi ethernet...
On the journey of life, I chose the psycho path.
smoke ::
Evo, sem se odlocil, da se jaz pristavim svojo skledo. :) Jaz sem drugi clovek v tem projektu. Malo sem prebral replyje in milo receno, sem bil razocaran, sem mislo da je slo-tech skupnost bolj osvescenih ljudi, ampak kot vidim, sem vsekal v temo. Pa da me nebote napadli, ces da govorim na pamet, bom bolj podrobno povedal zakaj tako mislim. Pa gremo..
Glede na to da ti je DustWolf povedal, da bo stvar 32bitna in, da je v replyih omenjen VGA, bi lahko sklepal, da misli x86 arhitekturo. Namrec, x86_64 je 64bitna arhitektura, ARM arhitektura pa je arhitektura za handheld naprave. Tam pa kolk vem ni VGA standarda.
Motis se, za pisanje v Linear Framebuffer rabis samo eno stvar. To je assembly ukaz MOV (Move), Virtual-8086 mode je cist nekaj druga (to uporablja Windows XP da emulira DOS.. kolker pac gre, seveda).
Se bi lahko navajal, ampak se mi vec ne da...
Lep pozdrav,
smoke
Če se tako otepate fosilov, kaj sploh počnete z VGA ?To da je VGA fosil je isto kot bi reko da je binary fosil, res da je na svetu ze zelo dolgo ampak brez tega ne gre. Glede dokumentacije od ATI-ja pa bom reko tak, tam so opisane bolj specificne stvari, se pravi tisto kar velja izkljucno samo za njihovo kartico. Se pravi si s tistim ne mores bogvekaj pomagat ce delas to kar delama midva z DustWolf-om.
ATI je dal dokumentacijo za doslej zaprte stvari, torej low level register stuff...Okej, ne vem tocno kaj si mislil ko si reko "low-level register stuff". To dejansko ne pomeni nic, se pravi, si se delal pametnega.
In kako ste si zamislili celo zadevo ? Mislim, kako je z:
....
- x86, x86_64, ARM, MIPS, tutti-frutti
Glede na to da ti je DustWolf povedal, da bo stvar 32bitna in, da je v replyih omenjen VGA, bi lahko sklepal, da misli x86 arhitekturo. Namrec, x86_64 je 64bitna arhitektura, ARM arhitektura pa je arhitektura za handheld naprave. Tam pa kolk vem ni VGA standarda.
Čisto možno,d a se motim. Kot mi je bilo razloženo, je to razlog, zakaj uvesafb driver potrebuje v86d...
Motis se, za pisanje v Linear Framebuffer rabis samo eno stvar. To je assembly ukaz MOV (Move), Virtual-8086 mode je cist nekaj druga (to uporablja Windows XP da emulira DOS.. kolker pac gre, seveda).
Mislil sem, zakaj se opirati na nek VESA, če to pomeni glavobole, če pa lahko flipneš par bitov v nekem registru kar sam ročno za to, da postaviš npr pravo bitno globino in ločljivost.Spet nevem kateri register mislis. Ampak bom probal odgovorit vseeno. Na VESA standard se mora opreti vsak programer ki pise svoj kernel in zeli da njegova koda kdaj kaj izpise/izrise na zaslon. Funkcij ki jih ponuja graficna kartica ne mores uporabit drugace kot pa da presaltas v realmode, naredis kar mislis in nato presaltas nazaj v protected mode.
Tukaj se strinjam z Branetom. Resno mislite, da je ASM prava resitev? Nevem no.Zakaj vedno ko se omeni Assembly jezik pride nekdo s takim inteligentnim odgovorom ven? So stvari, ki se dajo naredit samo v Assembly jeziku in to je ena od njih. Pa da se razumemo, enkrat in za vselej, assembly jezik ni izumrl in verjamite mi, da tisti, ki se tega zavedajo sluzijo velike denarce.
Kaj se bo zgodilo, ko bo nekdo sredi projekta ugotovil, da i386 ni več optimalni stroj, ker so tudi najcenejši mikrokrmilniki v bistvu i486 stroji ?Ce verjames ali pa ne, zgodilo se nebo cisto nic, ker edino kar je novega v i486 procesorju so MMX, FPU .. itd ukazi. General purpose ukazi, registri, vse je cisto enako.
Se bi lahko navajal, ampak se mi vec ne da...
Lep pozdrav,
smoke
Brane2 ::
Bodo pa šli pisat na novo. Saj jim ni cilj narediti drugega linuxa, kot je tip napisal jim je cilj se naučiti low-level delovanja sistema s tem da spišejo nek osnovni OS. V čem je smisel tega tvojega teženja za nečim brezveze zakompliciranim, ki se ne sklada z njihovimi cilji?
Proti učenju nimam NIČ. Je pa omenil neke "bistvene prednosti" tako optimizirane kode.
Ker se mi te prednosti niso zdele tako zelo bistvene, sem pač načel debato o prednostih samih- ne o smiselnosti projekta samega.
Drugače rečeno, nimam NIČ proti temu, da nekdo to počne. Stvar je le v tem, da deklarira prednosti tega početja, ki so torej po moji intepretaciji pa odprte za debato. Kakšne so dejanjsko te prednosti, kdaj pridejo in koliko do izraza in kakšne so slabosti ?
Nikoli nisem rekel "ne tega delat, cepec". Samo debatiram o tehničnih detajlih trditve, ki je bila podana.
Meni se recimo tistih nekaj MB kernela ne zdi bloat- ki bi ga bilo možno znatno oklestiti ob enaki funkcionalnosti.
Ja, mogoče, če laufaš stvar na mikrokrmilniku, ki je v nekem AP in bi rad soliden firewalling in hkrati solidno prepustnost in robustnost.
Ampak vprašanje če ti bo to pomagalo na klasičnem PCju bolj, kot če bi recimo začel s klasičnim kernelom, ki bi ga ustrezno oskubil in mu zamenjal stvari, ki ti niso všeč...
On the journey of life, I chose the psycho path.
DustWolf ::
ČE je predvidena funkcija te zadeve simpl grafični terminal, fajn. Če ni in bi rad vsaj nek tekst editor pa mogoče vsaj simpl browser, so problemi. Saj je kar nekaj kode zunaj za te zadeve, a mislim da ne na ta način- pisane v hand-optimised asm.
Če pa se spustiš še v pisanje tega, potem pa stvari sploh ne bodo več tako zelo minimalne.
V bistvu je stvar bolj premišljena kot to. VESA grafični vmesnik je standard. Tipkovnica je standard... če se sprijazniš z english layoutom. Miš, PS/2 je standard (nisem se še ukvarjal sicer po pravici povedano, mogoče pa ni). Ethernet, če si v PXE bootu, je standard.
In vsi ti standadi pomenijo da je implementacija ena sama in da je kode malo. Če se bo zakompliciralo bom pač odmislil podporo.
O.K. Ampak če sem prav dojel, to kar bi rrad izpeljal, boš lažje naredil na nekem simpl mikrokrmilniku. Nekaj v smislu Atmelovega AVR, mogoče v tamočni izvedenki ali kakim ARMom ali čem podobnim. Resda ni zasnovan na prejšnjih genereacijah CPUjev, je pa full poceni, majhen in _zelo_ malo porabi.
Jap ampak jaz pri lotanju ARMov v vezije popušim, zato bom ostal pri dobrih starih smeteh od PCjev. Sicer pa sem tudi na to mislil... moj cilj je bil nekako postaviti nek tak sistem, v katerem imaš lepo poomrežene vsakodnevne naprave. V tem sistemu sem si omislil PCe kot kontrolerje embeded napravic.
Faks nisem dokončal, pa tudi kaj dosti kode nismo obdelali tam ta čas. Sem se pa doma izživljal na osembitnih mlinčkih, šestnajstbitnih (QL_MC68008, Atari ST -68000 ), mikrokrmilnikih ( 80xx, PIC) in podobnih zadevah, sedaj pa se hecam z i86/x86_64.
No pač.. omenil sem zato ker ko enkrat delaš v ASM na PCu vidiš (ali pa tudi ne) kako si se prej j.... pri določenih jezikih in kako je vse simple v ASM. To je ta ideja.
O.K. Kje recimo linux kernel izgublja tako veliko časa, da bi se to splačalo ? Saj ne rečem,d a ga ne- koneckoncev obstaja kup alternativnih projektov, ampak kej je to tako izrazito, da to lahko pokažeš s prstom tako iz letala in pri tem oceniš "škodo", ki jo uporabnik trpi zaradi tega ?
Pač.. vsak OS ki se boota več kot 5 sekund po tem ko se prebere z medija je bloated. In vsak OS ki nekaj počne in čaka potem ko je uporabnik vnesel ukaz, preden se ukaz upošteva je počasen. Linux to je. Windows tudi.
Ravno te dni se hecam nekaj s kodo za izračunavanje P/Q paritete za RAID-5/6 polja in je na Linuxu napisana kar fino. Toliko, da težko najdem bistven plac za izboljšavo- v asm.
To mogoče ni najboljši primer tega kar sem jaz imel v mislih. V tem primeru gre pač za data pool ki ga moraš nekako pretvorit v drug data pool. V primeru kernela gre bolj za to kako boš nekaj dosegel, ne z katerimi ukazi.
kar pa se ostalega "bloata" tiče- hja nekdo ga je zahteval in tudi dobil - ker je Linus mislil, da je to lahko za nekoga dobra ideja.
Če smo natančni Linus ni nič mislil, ampak je samo naredil 100% kompatibilno implementacijo UNIXa. In to je točno tisto česar mi ne nameravamo narest. Veselo dedovat probleme iz preteklih zgrešenih konceptov.
Sploh pa, koliko časa preživijo aplikacije dejanjsko v kernelu ?
Ta dobi zahtevo in jo obdela- v veliki večini gre za zahteve nekim napravam, task scheduling in irq response.
To ni tako bistveno kot to kaj kernel ponuja in koliko rabi aplikacija živet v kernelu.
Pa saj compiler ti omogoča skok v asm kadarkoli ti to zapaše sredi samega sourcea. Sam pri (resda bežni) analizi v običajnih fileih nisem zapazil nekega strašnega razmetavanja z resursi. Tam, kjer pa compiler bistveno fali, pač stvari popraviš ročno...
Ja superca.. GAS sintaksa. Najbolj retardiran assembly v zgodovini človeštva. Ne hvala, ostajam pri FASM.
Tu je sploh ni. Poanta je bila nekoč, ko so bile neke kartice še čisto tekstualne in ti je VGA ponujala varen default.
Ali ko so bile prve implementacije framebuferja skarjno blesave in si vanj videl po straneh od 16KB.
Ves tovrstno blesav hardver je že davno izven uporabe, in praktično vse ti ponuja framebuffer. Zakaj bi se torej še zaj* s tekstualnim modom ?
Ker:
Za text mode naredit rabiš nič kode.
Za grafični mode naredit rabiš nenič kode.
Ja, vpis enega namesto osmih byteov pa res drastično spremeni stvari, sploh ob pametni organizaciji podatkov in upoštevanju filanja cachelineov- ko si dosegel prvi byte, so naslednji 3-je v istem registru in naslednji 4-12 že praktično v cachelineu...
Pa ta izvedba ti tudi poenostavi delo za zaslonom - vse vidiš kot grafiko.
In če si zaj.. nekje v kodi pred tem in tvoja koda za pretvarjanje ne deluje pravilno ne vidiš ničesar. Blazno helpful debug ja.
LP
BigWhale ::
Tukaj se strinjam z Branetom. Resno mislite, da je ASM prava resitev? Nevem no.Zakaj vedno ko se omeni Assembly jezik pride nekdo s takim inteligentnim odgovorom ven? So stvari, ki se dajo naredit samo v Assembly jeziku in to je ena od njih. Pa da se razumemo, enkrat in za vselej, assembly jezik ni izumrl in verjamite mi, da tisti, ki se tega zavedajo sluzijo velike denarce.
No, glede na tvoj profil, bi ti lahko rekel, da sem se z assemblerjem ukvarjal se preden si ti iz plenic zlezel. :)
Imas prav, nekatere stvari lahko naredis samo v assemblerju se zdalec to ne pomeni, da drugih stvari ne mores narediti precej lazje in hitreje in dandanes z danasnjimi prevajalniki prakticno brez nekih resnih izgub v hitrosti, v kaksnem drugem jeziku.
Kar se pa inteligence odgovora tice, je bil tvoj kaj bolj inteligenten? Si dejansko kako argumentiral zakaj bo vse pisano v ASMju? Iz vseh postov skupaj je bilo za razbrat, da samo zato, ker se vam zdi cool. In ker so vsi zdajsnji kerneli zavozeno sranje. :)
Imate kak pameten argument zakaj bo vse spisano v ASMju? Ce ja, bi ga rad slisal.
PS: Boste open sourcali zadevo?
Zgodovina sprememb…
- spremenil: BigWhale ()
Brane2 ::
Glede dokumentacije od ATI-ja pa bom reko tak, tam so opisane bolj specificne stvari, se pravi tisto kar velja izkljucno samo za njihovo kartico. Se pravi si s tistim ne mores bogvekaj pomagat ce delas to kar delama midva z DustWolf-om.
Možno. AMpak očitno je ves projekt itak zelo ozko usmerjen. Kaj je narobe s tem, če ga vežete na enega, relativno velikega proizvajalca kartic, katerega odprte specifikacije obsegajo nekaj družin ?
Okej, ne vem tocno kaj si mislil ko si reko "low-level register stuff". To dejansko ne pomeni nic, se pravi, si se delal pametnega.
Ja, če ti ne veš, kaj sem mislil z vprašanjem, to pomeni,d a sem se delal pametnega. Druge opcije ni, ker si ti pametnejši od mene. Če bi jaz nekaj mislil, bi ti to ziher vedel.
Seveda. Le kako bi lahko bilo drugače- saj le ti vidiš "In the Matrix".
Drugače pa, mislil sem to, kar sem rekel. Low register stuff. V kateri register moraš vpisati kaj, da spremeniš refresh rate RAMa na kartici, CLK timing itd itd. Enako za video shifter in ostalo. Od pixel clocka, barvne globine, začetka slike v RAMu, kojekakvih overlayev itd itd.
Glede na to da ti je DustWolf povedal, da bo stvar 32bitna in, da je v replyih omenjen VGA, bi lahko sklepal, da misli x86 arhitekturo. Namrec, x86_64 je 64bitna arhitektura, ARM arhitektura pa je arhitektura za handheld naprave. Tam pa kolk vem ni VGA standarda.
Potem bi kazalo updateati to, kar veš. VGA stuff je implemtirran tudi za PCI in PCI je zamišljen kot univerzalno vodilo, torej...
Videl sem recimo implementacijo VGA na MC68000 in to na ISA vodilu. Tudi v nekaterih SoC zadevah je AFAIK vga compatible stuff itd.
Spet nevem kateri register mislis. Ampak bom probal odgovorit vseeno. Na VESA standard se mora opreti vsak programer ki pise svoj kernel in zeli da njegova koda kdaj kaj izpise/izrise na zaslon. Funkcij ki jih ponuja graficna kartica ne mores uporabit drugace kot pa da presaltas v realmode, naredis kar mislis in nato presaltas nazaj v protected mode.
Za nekoga, ki pozna MAtrix maš prav glupe izpade. Kako hudiča ne moreš mimo VESA, če svojo nVidia kartico lahko trajbam tako skozi vesa driver kot tudi skozi direkten nvidia driver, tako odprtokodni kot zaprtokodni ?
VESA je samo "lep", standardizirano zapakiran način dostopanja do nekaterih resursov kartice.
Ce verjames ali pa ne, zgodilo se nebo cisto nic, ker edino kar je novega v i486 procesorju so MMX, FPU .. itd ukazi. General purpose ukazi, registri, vse je cisto enako.
Spet ena glupa. Jasno je,d a je i486 združljiv z i386. Ni pa to več res v optimiziranem kernelu. Ja, stvari bodo najbrž delale še naprej, ampak celotan poanta kernela bo zgubljena, saj ne bo več optimalen za novi stroj- to pa je njegov "primary selling point".
Evo ti en primerček. Koda v kernelu ima več rutin za generacijo omenjenih polinomov paritete za RAID-5/6.
Ob zagonu kernela/loadu raid456 modula ta izvede interni benchmark in uporabi rutino, ki je najboljša na danem stroju.
Evo ti dmesga benchmarka ob bootu za
Phenom (9850-2.5GHz):
[ 6.032462] md: raid0 personality registered for level 0
[ 6.032556] md: raid1 personality registered for level 1
[ 6.032651] md: raid10 personality registered for level 10
[ 6.100009] raid6: int64x1 2602 MB/s
[ 6.168024] raid6: int64x2 3317 MB/s
[ 6.236014] raid6: int64x4 3010 MB/s
[ 6.304033] raid6: int64x8 2343 MB/s
[ 6.372010] raid6: sse2x1 3505 MB/s
[ 6.439999] raid6: sse2x2 5868 MB/s
[ 6.508004] raid6: sse2x4 7090 MB/s
[ 6.508099] raid6: using algorithm sse2x4 (7090 MB/s)
[ 6.508188] md: raid6 personality registered for level 6
[ 6.508283] md: raid5 personality registered for level 5
[ 6.508377] md: raid4 personality registered for level 4
ZA AMD64 x2 6000+ :
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
raid6: int64x1 2807 MB/s
raid6: int64x2 3988 MB/s
raid6: int64x4 4245 MB/s
raid6: int64x8 2693 MB/s
raid6: sse2x1 1400 MB/s
raid6: sse2x2 2341 MB/s
raid6: sse2x4 3532 MB/s
raid6: using algorithm sse2x4 (3532 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid5: device sda operational as raid disk 0
raid5: device sdf operational as raid disk 7
raid5: device sdg operational as raid disk 6
raid5: device sdh operational as raid disk 5
raid5: device sde operational as raid disk 4
raid5: device sdc operational as raid disk 3
raid5: device sdd operational as raid disk 2
raid5: device sdb operational as raid disk 1
raid5: allocated 8474kB for md_d0
raid5: raid level 5 set md_d0 active with 8 out of 8 devices, algorithm 2
Kernel torej pri K8 izbere drugo rutino, kot jo izbere pri K-10. K-10 nis samo hitrejši od K-8 ampak je njegov pospešek lahko v določenih situacijah tudi pojemek. Če bi kernel uporabljal za K-8 optimalno rutino "int64x4", bi bil tam pri prehodu na novi stroj 30% počasnejši namesto 1.x krat hitrejši.
Če bi se to zgodilo v tvojem hand optimised kernelu, bi bilo to še posebno slabo, ker bi bil tak kernel v bistvu hand-pessimized za K-10.
KAr velja za K-8/K-10, velja tudi za 386/486. Instruction cost ni vedno isti za oba stroja in variante, ki so optimalne za enega, so lahko slabe za drugega.
Se bi lahko navajal, ampak se mi vec ne da...
Neo ni bil tak frajer, ker je imel cool glasses in fancy footwork ampak ker je porival Trinity.
In to da on pa kao vidi "dlje od ostalih" se je IIRC dokaj slabo končalo. Pest, ki se mu je usedla na ksiht in mu zdrobila cvikerje, ni zgledala prav nedolžno.
Seveda to ni ustavilo prodaje cvikerjev in plaščev, pa verjetno tudi kakega kanona.
Folk še vedno misli, da če bo pa začel ukvarjat z asm, bo pa na ravni boga.
Nimam v bistvu nič proti in ne mislim, da so neumni ali kaj posebej razsvetljeni že zaradi tega.
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
DustWolf ::
No, glede na tvoj profil, bi ti lahko rekel, da sem se z assemblerjem ukvarjal se preden si ti iz plenic zlezel. :)
Smoke obvlada ASM... ko boš ti tolko znal ko on se oglašaj ampak ajd... sj vem da ne moreš vedet na podlagi tistega kar tam piše.
Imate kak pameten argument zakaj bo vse spisano v ASMju? Ce ja, bi ga rad slisal.
Glej, tega ti ne moremo povedat če ne razumeš v čem je caka. Ker bo pač tvoj odgovor tak kot si ga napisal tu. Zgoraj je obširna debata na to temo, ko jaz poizkušam razložit Branetu da, zaboga, optimizacija kode ni samo prekladanje ukazov da pašejo v pipeline, ipd. Priznam da mogoče ne znam razlagat ampak bare with me.
Jst ne vem kako bi ti to razložu, zato ker sem še jst to skapiral šele potem ko sem se res lotil ASM.
ASM je pač bolj neposreden in se da napisat vse tisto v njem kar lahko v vseh ostalih jezikih skup. Ampak pri večini jezikov je neko ovinkarjenje.. zato da narediš optimalen sistem moraš vedet kako izgleda v ASM, in če boš šel to delat v Cju boš moral:
1. V glavi compilat kodo
2. Vozit slalom v Cju zato da bo prava koda nastala
To nima smisla, zato pišemo raje direkt v ASM.
PS: Boste open sourcali zadevo?
Ne vidim razloga zakaj ne ampak zaenkrat je koda še zmazek, ki ga ne bo nihče razumel (razen tisti ki visimo na CVSu in se pogovarjamo sproti). Tak da to bomo morali še pripravit. :)
smoke ::
No, glede na tvoj profil, bi ti lahko rekel, da sem se z assemblerjem ukvarjal se preden si ti iz plenic zlezel. :)Okej hehe, temu nebom ugovarjal. :) Kar se pa tice tega:
Imas prav, nekatere stvari lahko naredis samo v assemblerju se zdalec to ne pomeni, da drugih stvari ne mores narediti precej lazje in hitreje in dandanes z danasnjimi prevajalniki prakticno brez nekih resnih izgub v hitrosti, v kaksnem drugem jeziku.V katerem jeziku pa? C#, Java ? Nebo slo. Ce pa mislis C/C++ pa ti lahko povem, da je v bistvu (skoraj) enako al programiras v Assemblyju ali pa v Cju, razlika je v sintaksi (seveda) in pa v tem da v Cju nimas dostopa do stacka. C je le malenkost bolj highlevel kot Assembly. Ampak ce uporabis Assembly imas bolj proste roke.. se lahko bolj igras. Pa se koda je dost hitrejsa. In to je nekak nas cilj. :)
Možno. AMpak očitno je ves projekt itak zelo ozko usmerjen. Kaj je narobe s tem, če ga vežete na enega, relativno velikega proizvajalca kartic, katerega odprte specifikacije obsegajo nekaj družin?Vidim da se kr nimas blage veze o cem govoris. Da postane ATIjeva dokumentacija uporabna moras met ze velik del sistema napisan. Ker kolker vidim, dokumenti opisujejo 3d grafiko.. itd.
Ja, če ti ne veš, kaj sem mislil z vprašanjem, to pomeni,d a sem se delal pametnega. Druge opcije ni, ker si ti pametnejši od mene. Če bi jaz nekaj mislil, bi ti to ziher vedel.Potem bo pa ze res da se, pametnejsi od tebe. Vidim da pojmov kot so: low-level, register nimas razciscenih v glavi.
Za nekoga, ki pozna MAtrix maš prav glupe izpade. Kako hudiča ne moreš mimo VESA, če svojo nVidia kartico lahko trajbam tako skozi vesa driver kot tudi skozi direkten nvidia driver, tako odprtokodni kot zaprtokodni ?Seveda lahko "trajbas" skoz nvidia driver, ampak kako pa mislis da nvidia driver izrise stvari na zaslon ? S pomocjo magije? Sicer pa, poglej si sam. Prej sem zasledil da si rekel da se ukvarjas z x86/x86-64 assemblyjem, disassemblaj nvidiin driver in si poglej kak naredi. Da se nebos mucil prevec .. ti lahko povem da ima nvidiin miniport driver importane funkcije samo iz videoprt.sys driverja. Ce pa malo podrobno pogledas katere funkcije ima pa videoprt.sys exportane pa bos videl da je ena izmed njih VideoPortInt10. I wonder what it does..
je samo "lep", standardizirano zapakiran način dostopanja do nekaterih resursov kartice.
Spet ena glupa. Jasno je,d a je i486 združljiv z i386. Ni pa to več res v optimiziranem kernelu. Ja, stvari bodo najbrž delale še naprej, ampak celotan poanta kernela bo zgubljena, saj ne bo več optimalen za novi stroj- to pa je njegov "primary selling point".Kar se tice optimizacije, koda se najprej napise, se le potem se optimizira. In to ne pomeni da bomo potem morali se enkrat napisat celo kodo ki bo optimizirana.. Poleg tega.. zakaj bi moral zarad optimizacije ostati i386 nepodprt ?
P.S.: Nikjer nisem trdil, da poznam Matrico. O.o .. Ce pa sklepas po nicku, si se pa zmotil..
Zgodovina sprememb…
- spremenil: smoke ()
BigWhale ::
Smoke obvlada ASM... ko boš ti tolko znal ko on se oglašaj ampak ajd... sj vem da ne moreš vedet na podlagi tistega kar tam piše.
No, ti zgleda se zdaj nisi iz plenic zlezel? Znata debatirati na nekem nivoju? Dajta se debatirat tako dobro kot kodirata. Al pa vsaj pol tolk? Prav?
Imate kak pameten argument zakaj bo vse spisano v ASMju? Ce ja, bi ga rad slisal.
Glej, tega ti ne moremo povedat če ne razumeš v čem je caka. Ker bo pač tvoj odgovor tak kot si ga napisal tu.
Ne, lej, jaz sem vprasal, ce je ASM res prava resitev problema in kaj vse nameravate napisati v ASMju. Odgovora pa nisem dobil, ker si takoj zacel bluzit o 'inteligentnih vprasanjih'.
Zgoraj je obširna debata na to temo, ko jaz poizkušam razložit Branetu da, zaboga, optimizacija kode ni samo prekladanje ukazov da pašejo v pipeline, ipd. Priznam da mogoče ne znam razlagat ampak bare with me.
Zgoraj je pretezno in na zalost obsirna debata kako imas ti vecjega kot Brane.
ASM je pač bolj neposreden in se da napisat vse tisto v njem kar lahko v vseh ostalih jezikih skup. Ampak pri večini jezikov je neko ovinkarjenje.. zato da narediš optimalen sistem moraš vedet kako izgleda v ASM, in če boš šel to delat v Cju boš moral:
Danasnji compilerji kodo ze precej dobro optimizirajo. Casovno manj zahtevno je, ce se stvari lotis v Cju in potem ugotavljas bottle-necke s profilingom. Razlike men tako kodo in pure ASM kodo bodo marginalni. Hkrati bos pa prihranil pri casu.
1. V glavi compilat kodo
2. Vozit slalom v Cju zato da bo prava koda nastala
To nima smisla, zato pišemo raje direkt v ASM.
V Cju ponavadi prej odpeljes dva veleslaloma preden ti ASM spesnis... :)
Saj ne recem, ASM je za dolocene potrebe vec kot odlicen in je prav, da se ga uporablja ampak pisanje celotnega OSa v ASM (pa ceprav je to samo solski primer) pa nima nekega smisla, kot to, da ostane 'pet project' dokler imas cas.
Trenutno je vas argument zakaj ASM samo hitrost.
BigWhale ::
V katerem jeziku pa? C#, Java ? Nebo slo. Ce pa mislis C/C++ pa ti lahko povem, da je v bistvu (skoraj) enako al programiras v Assemblyju ali pa v Cju, razlika je v sintaksi (seveda) in pa v tem da v Cju nimas dostopa do stacka. C je le malenkost bolj highlevel kot Assembly. Ampak ce uporabis Assembly imas bolj proste roke.. se lahko bolj igras. Pa se koda je dost hitrejsa. In to je nekak nas cilj. :)
Seveda govorim o Cju. ASM je pa pogojno hitrejsi. Tko kot sem ze nekajkrat rekel, da so dandanes compilerji ze precej dobri in so razlike v hitrosti tako minimalne, da se enostavno ne splaca ponucati petkrat vec casa zato, da je potem koncni izdelek za nekaj promilov hitrejsi.
Brane2 ::
Da postane ATIjeva dokumentacija uporabna moras met ze velik del sistema napisan. Ker kolker vidim, dokumenti opisujejo 3d grafiko.. itd.
Opisujejo natanko vse to kar rabiš za svoj low_level hands_on_the_metal approach.
Kje je fora imeti kao hand optimised kernel s shitloadom zadev ob VESA in praktično neizkoriščenem HWju ?
Valjda se razume, da potem pišeš direktno v registre oziroma PCI mapped memory, seveda ob optimalno nastavljenih MTRR in ob upoštevanju možnosti HW ( X-way asociativnosti cachea, Y-cycle deep write bufferinga in seveda vseh povezanih latenc, da lahko podatke zadosti zgodaj PREFETCHaš v nekem 386 ekvivalentu, če ta obstaja.
Seveda lahko "trajbas" skoz nvidia driver, ampak kako pa mislis da nvidia driver izrise stvari na zaslon ? S pomocjo magije? Sicer pa, poglej si sam. Prej sem zasledil da si rekel da se ukvarjas z x86/x86-64 assemblyjem, disassemblaj nvidiin driver in si poglej kak naredi. Da se nebos mucil prevec .. ti lahko povem da ima nvidiin miniport driver importane funkcije samo iz videoprt.sys driverja. Ce pa malo podrobno pogledas katere funkcije ima pa videoprt.sys exportane pa bos videl da je ena izmed njih VideoPortInt10. I wonder what it does..
kernel: vanilla-sources-2.6.27-rc7
dir: /drivers/video/nvidia/
Mi lahko kaj takega pokažeš?
Sedaj sem na brzino preletel open source driver, pa vidim nič drugega kot kup enih stvari za ugotavljanje in nastavljanje bitne globine in različnih geometrij, za prepoznavanje kartice med PCI scanom, za i2c komunikacijo za EDID itd.
Naj te spomnim: trdil si da VESA nujno rabiš. And yet, tu ni nikjer niti omenjeno nič podobnega.
Care to explain that ?
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
DustWolf ::
No, ti zgleda se zdaj nisi iz plenic zlezel? Znata debatirati na nekem nivoju? Dajta se debatirat tako dobro kot kodirata. Al pa vsaj pol tolk? Prav?
Jaz nisem nikjer zlezel pod nivo v celem threadu. Razložu sem lepo vsako vprašanje. Če si smoka razjezil pač ne morem pomagat ti je pač napisal svoje.
Ne, lej, jaz sem vprasal, ce je ASM res prava resitev problema in kaj vse nameravate napisati v ASMju. Odgovora pa nisem dobil,
Naj ti torej razjasnim že povedano: Mislimo da je ASM dobra izbira zaradi.. glej zgoraj. V ASM bo napisano vse. Oziroma tako zgleda stvar zdaj. Če se izkaže da se da v kakem drugem programskem jeziku lepo pisat programe za to platformo potem bomo... zaenkrat mi to sicer ni očitno.
Zgoraj je pretezno in na zalost obsirna debata kako imas ti vecjega kot Brane.
In potem mene kriviš da sem šel pod nivo... Sori če ne razumeš ampak ko boš boš videl kaj sem hotu povedat. Jaz se kregat nimam namena in se mi zdi da je to vsaj Brane bolj razumel kot ti.
Danasnji compilerji kodo ze precej dobro optimizirajo.
Ja, lepo, fajn, super. Ampak a si sploh videl vse ostalo kar sem napisal al maš ti prav in ti je vseeno glavno da svoje nabijaš?
Zarad mene lahko Compilerji na glavi stojijo pa žonglirajo, če se da v ASM bolj direkt napisat kar pišeš, kar hočeš napisat, je ASM boljša izbira. Mislim da to ni tako iracionalno. Novega koncepta pač ne morem it delat v Cju, če koncept ni v ničemer podoben vsej kodi ki je do sedaj že napisana, razen v tem da dela na istem hardwareu. Nima smisla, mam lepši pregled v ASM.
Razlike men tako kodo in pure ASM kodo bodo marginalni.
Če jaz v Cju sploh ne morem narest tistega kar sem si jaz zamislil ne bodo razlike prav nič marginalne. Tudi pri času ne bom prišparal če rabim delat kroge okrog tistega kar hočem narest. Primer: hočem flipnit en bit v CPU:
ASM:
mov eax,cr0
or al,1
mov cr0,eax
C:
Čira čara, 50 vrstic includov, če se sploh da.
..v malem kernelu je pač večina stvari takih.
V Cju ponavadi prej odpeljes dva veleslaloma preden ti ASM spesnis... :)
Ampak jaz v ASM prej spisem N tvojih procedur preden ti meni v Cju narediš eno ki zanesljivo deluje. Ker C pobira komponente od vsepovsod in ti ne veš kaj nastane iz tega. Da bi pa ti razumel kaj se dejansko dogaja zadaj moraš pa v glavi compilat kodo in točno vedet kaj nastane, kako se ukazi izvajajo, kaj se zgodi, kaj se lahko zgodi. In če neveš kaj se dogaja zadaj, ne moraš garantirat da bo delovala zanesljivo.
Sem delal že na dovolj komercialnih projektih da vem kaj govorim. Za simple low level stuff, C pač ni. Razen v nekem akademskem okolju, kjer bi ti v končni fazi svetovali tudi da zadevo napišeš v Javi, samo da jo bodo lahko še kje ponucali.
Saj ne recem, ASM je za dolocene potrebe vec kot odlicen in je prav, da se ga uporablja ampak pisanje celotnega OSa v ASM (pa ceprav je to samo solski primer) pa nima nekega smisla, kot to, da ostane 'pet project' dokler imas cas.
Problem te tvoje izjave je v tem da ti pač nimaš pojma o čem pišeš. Edini razlog zakaj vsi ti odgovori izgledajo enako je zato ker jih vsi prepisujete iz iste knjige. Kake logike za tem ni.
Priznam C je bolj primeren za pisanje stvari ki so že napisane, vržeš par includov noter in si končal. Ampak je pa cel kup stvari ki jih v Cju pač ne moreš it delat. Jaz ponavadi mešam programske jezike da gre hitreje -- ampak osnovne komponente ki delajo enostavne stvari vedno spišem kot DLLje v FASM, ker so bistveno bolj zanesljive take kot karkoli kar se zanaša na to da bo nekdo drug nekaj naredil prav. In kernel, so same osnovne komponente.
Trenutno je vas argument zakaj ASM samo hitrost.
In temu je pač tako ker ti situacije ne poznaš dovolj dobro da bi lahko videl še kako drugo prednost.
DustWolf ::
Kje je fora imeti kao hand optimised kernel s shitloadom zadev ob VESA in praktično neizkoriščenem HWju ?
Ja sori ker ne bo ravno konzola 3D pospešena.
Ta tvoj cel argument je malo mimo:
1. Nikol nismo rekli da bomo optimiziral na pipeline, itd -- ko pišeš stvar ground-up v ASM imaš proste roke da veliko stvari napišeš bolje kot so sedaj napisane. Naprimer: Ne rabim kernela + vsega živega + X serverja zato da naredim decent grafični vmesnik. Lahko naredim samo kernel z grafičnim vmesnikom in mam 0,005% kode.
2. Nikol ni blo rečeno da bomo sledil kakim trednom -- že 15ič, stvar bo lavfala na stari šari. Za staro šaro je bistveno bolj pomembno da dela povsod kot to da je nevem kako fancy. i386 in VESA framebuffer je tu idealna izbira -- to podpira vsa stara šara ki jo imam doma.
3. Tvoj koncept da boš uporabil OpenGL namesto kakega tekstovnega vmesnika je rahlo zgrešen... mešaš jabolka in pomaranče, s tem ko mečeš Cjeve knjižnjice in GPU arhitekturo v isti koš -- to nekako daje smoku merilo po katerem ocenjuje tvoje poznavanje problematike -- iz njegovega vidika tebe pač v kernelu moti pomanjkanje buzzwordov
Nothing personal ampak pač... če misliš da je naša ideja napačna -- let it be and wait and see. Za pomoč očitno ne boš... če nas ne maraš. Mi iščemo koga ki se mu ideja pisanja kernela na novo -- tokrat brez napak -- zdi dobra.
Bom pa seveda odgovoril na vsa tehnična vprašanja.
Brane2 ::
Nasprotno. Ideja se mi zdi v osnovi cool, tudii če nekako ni na moji valovni dolžini.
Sprašujem smao zato, ker ste pač tu objavili predstavitev projekta. Vsaka dobra ideja mora biti sposobna prenseti ne samo naklonjena ampak tudi nenaklonjena vprašanja- biti videna z vseh strani.
Koneckoncev je to verjetno to, kar bo zanimalo vsakega potencialnega newcomerja- stvari, i mogoče v prvih 15 sekundah navdušenja niso bile očitne. Če nič drugega, to izfiltrira navdušence s short attention spanom od folka, ki pa mogoče dejanjsko nekaj bi.
Sprašujem smao zato, ker ste pač tu objavili predstavitev projekta. Vsaka dobra ideja mora biti sposobna prenseti ne samo naklonjena ampak tudi nenaklonjena vprašanja- biti videna z vseh strani.
Koneckoncev je to verjetno to, kar bo zanimalo vsakega potencialnega newcomerja- stvari, i mogoče v prvih 15 sekundah navdušenja niso bile očitne. Če nič drugega, to izfiltrira navdušence s short attention spanom od folka, ki pa mogoče dejanjsko nekaj bi.
On the journey of life, I chose the psycho path.
Brane2 ::
3. Tvoj koncept da boš uporabil OpenGL namesto kakega tekstovnega vmesnika je rahlo zgrešen...
Ne _namesto_ ampak _ob_. In ne OpenGL ampak po možnosti HW direktno. Za kaj hudiča bi to rabil ?
Paaa, recimo da ti omenjeno pariteto za RAID polje namesto CPU preračunava GPU. Kje je korist od tega ? Pa, če imaš recimo plato z vdelanim, relativno počasnim GPUjem in seveda na njej pošteno grafikuljo, lahko vdelani GPU mirno uporabiš za take posle.
Še več, stvar je podatkom ravno na poti od diska do CPU RAM-a in nazaj, torej ni potrebno najprej vse skupaj prebrati, izračunati P/Q in nato vpisati vse skupaj.
Še en primer ? Stvar je "dušu dala" za enkripcijo tako diska kot posameznih particij in datotek, brez bistvene izgube performans.
Še enga ? Pa ajde, če insistiraš- in flight resampling za zvočno, če ga ta potrebuje.
mešaš jabolka in pomaranče, s tem ko mečeš Cjeve knjižnjice in GPU arhitekturo v isti koš -- to nekako daje smoku merilo po katerem ocenjuje tvoje poznavanje problematike -- iz njegovega vidika tebe pač v kernelu moti pomanjkanje buzzwordov
Nisem imel teh namenov. Le pravim, da se vsaj _meni_ zdi nekompletno delati na kao _lean_and_mean_ kernelu in ostalem SW, ki pa za grafični izhod "komplicira" z VESA in pušča težko artiljerijo, tudi če je ta prisotna, neuporabljeno.
Poleg tega, na podoben način lahko gledam nate (kot ti/vi name). Če bi rad prišel do nekega visokega cilja, ponavadi izbiraš optimalno pot.
Pri klestenju drevesa možnih poti ste odklestili ogromen del krošnje samo zato, ker "pušiš pri lotanju ARMa"- stvari ki poštenemu HW navdušencu ne bi smela vzeti več ko 30 sec, ajde minuto.
Po tej vaši logiki je smrten greh, če si "kmet za registre" ampak če si "lotkolm_peder" je pa to nekako "welcome to the club"-normala in pravzaprav danost.
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
DustWolf ::
Paaa, recimo da ti omenjeno pariteto za RAID polje namesto CPU preračunava GPU. Kje je korist od tega ? Pa, če imaš recimo plato z vdelanim, relativno počasnim GPUjem in seveda na njej pošteno grafikuljo, lahko vdelani GPU mirno uporabiš za take posle.
Še več, stvar je podatkom ravno na poti od diska do CPU RAM-a in nazaj, torej ni potrebno najprej vse skupaj prebrati, izračunati P/Q in nato vpisati vse skupaj.
Uhh.. težka filozofija.. Ampak zarad mene...
Upoštevaj samo to da program ki to počne teče na CPU in da CPU čaka med tem ko ti izvajaš I/O (tu bi se lahko zlobno pošalil da samo zaradi tega ker ti tvoja Cjeva knjižnjica tega ne kaže še ne pomeni da se ne dogaja), na chipset, bus, itd. Morda je stvar malo ubijalska v praksi.
Še en primer ? Stvar je "dušu dala" za enkripcijo tako diska kot posameznih particij in datotek, brez bistvene izgube performans.
Mislim da sem za ta namen že videl FPGA čipe ki gredo na PCIE bus, jih software sprogramira in potem predelujejo podatke v realnem času. Seveda.. v praksi to pomeni da še vedno CPU čaka...
Nisem imel teh namenov. Le pravim, da se vsaj _meni_ zdi nekompletno delati na kao _lean_and_mean_ kernelu in ostalem SW, ki pa za grafični izhod "komplicira" z VESA in pušča težko artiljerijo, tudi če je ta prisotna, neuporabljeno.
Imaš kako boljšo idejo kako bi stvar delala na vsem hardwareu ki ga imam jaz med staro šaro?
Naj te spomnim, noben računalnik iz moje stare šare nima AGP slota.
Poleg tega, na podoben način lahko gledam nate. Če bi rad prišel do nekega visokega cilja, ponavadi izbiraš optimalno pot.
Pri klestenju drevesa možnih poti so odklestil ogromen del krošnje samo zato, ker "pušiš pri lotanju ARMa"- stvari ki poštenemu HW navdušencu ne bi smela vzeti več ko 30 sec, ajde minuto.
Torej nisem pošten HW navdušenec. My bad. Kaj pa sedaj? Ne smem pisat kernela?
Čisto praktično mi je bolj enostavno napisat tale kernelčič za i386, ker imam polno stare šare z mrežnimi karticami, crknjenimi diski, ipd. In verjetno nisem edini. V mojem fohu se pač ukvarjam z kontrolo mašinerije iz računalnikov, in mi Windows bugi že čez ušesa ven gledajo. Zato bom pomagal narediti kernel ki je idealen za ta namen in nima istih napak.
Groza ane..
Brane2 ::
Aja, še to.
Nekaj ljudi dejanjsko še uporablja SoC 386/486 variante čipovja, ampak vsi so šli v to, zaradi neke kompatibilnosti z obstoječim SW- torej zanje tovrstne optimizacije ne bi prišle v poštev.
Reciklaža starega HW je sicer lepa ideja, ampak pri toliko starem HW bi mogoče kazalo razmisliti, če ni koneckoncev korist mogoče negativna in bi zadeva samo skozi plac in štrom požrla svojo vrednost.
IMHO je kup bolj zanimivih stvari, kjer bi tak pristop požel lahko uspeh. Je na kupe presenetljivo močnih mikrokrmilnikov, kjer ti razvojni board skorajda podarijo, čipi sami zase pa tudi niso dragi.
Heck, mnogi WiFi APji in celo switchi so lahko idealen playground, ker imajo že vse na tiskanini pa še JTAG za programiranje.
Ali pa recimo izpeljava kakega full enostavnega CPUja na poceni FPGAju, povezava na DRAM in programiranje.
To bi recimo zažigalo vsaj zame bistveno bolj kot i386.
In olajšalo študenstko življenje s prenekaterim plačanim projektom, če že ne odprlo pot v službo...
Nekaj ljudi dejanjsko še uporablja SoC 386/486 variante čipovja, ampak vsi so šli v to, zaradi neke kompatibilnosti z obstoječim SW- torej zanje tovrstne optimizacije ne bi prišle v poštev.
Reciklaža starega HW je sicer lepa ideja, ampak pri toliko starem HW bi mogoče kazalo razmisliti, če ni koneckoncev korist mogoče negativna in bi zadeva samo skozi plac in štrom požrla svojo vrednost.
IMHO je kup bolj zanimivih stvari, kjer bi tak pristop požel lahko uspeh. Je na kupe presenetljivo močnih mikrokrmilnikov, kjer ti razvojni board skorajda podarijo, čipi sami zase pa tudi niso dragi.
Heck, mnogi WiFi APji in celo switchi so lahko idealen playground, ker imajo že vse na tiskanini pa še JTAG za programiranje.
Ali pa recimo izpeljava kakega full enostavnega CPUja na poceni FPGAju, povezava na DRAM in programiranje.
To bi recimo zažigalo vsaj zame bistveno bolj kot i386.
In olajšalo študenstko življenje s prenekaterim plačanim projektom, če že ne odprlo pot v službo...
On the journey of life, I chose the psycho path.
DustWolf ::
In olajšalo študenstko življenje s prenekaterim plačanim projektom, če že ne odprlo pot v službo...
Na tem področju tudi poznavanje delovanja hardwarea in kernelov ni tak švoh...
Jaz na šihtu pridobljeno znanje kar veselo koristim.
Brane2 ::
Torej nisem pošten HW navdušenec. My bad. Kaj pa sedaj? Ne smem pisat kernela?
Ene tolk kot jaz ali kdorkoli drug.
Čisto praktično mi je bolj enostavno napisat tale kernelčič za i386, ker imam polno stare šare z mrežnimi karticami, crknjenimi diski, ipd. In verjetno nisem edini. V mojem fohu se pač ukvarjam z kontrolo mašinerije iz računalnikov, in mi Windows bugi že čez ušesa ven gledajo. Zato bom pomagal narediti kernel ki je idealen za ta namen in nima istih napak.
Fair enough. Tvoj čas, tvoja pravica/problem. Nič bolj ali manj kot kup, v glavnem neposrečenih stvari, v kateree sem se spustil, pa bi jih ponovil tudi če bi me vrnili skozi čas nazaj, ker enostavno ne bi bil zdrav če ne bi probal.
Človek je subclass opice, temu ne uideš. "Monkeying around" fraza pove vse ;o)
On the journey of life, I chose the psycho path.
Brane2 ::
Upoštevaj samo to da program ki to počne teče na CPU in da CPU čaka med tem ko ti izvajaš I/O (tu bi se lahko zlobno pošalil da samo zaradi tega ker ti tvoja Cjeva knjižnjica tega ne kaže še ne pomeni da se ne dogaja), na chipset, bus, itd. Morda je stvar malo ubijalska v praksi.
V bistvu AFAIK ne. C knjižnica je odgovorna samo za predajo programa in podatkov GPUju in poznejši sprejem rezultatov.
Linux kernel pa te zadeve prav lepo obvlada. Pač preda podatke zunanji enoti v obdelavo in rezervira therad, ki naj se požene, ko pridejo. V vmesnem času pa počne kaj drugega.
Mislim da sem za ta namen že videl FPGA čipe ki gredo na PCIE bus, jih software sprogramira in potem predelujejo podatke v realnem času. Seveda.. v praksi to pomeni da še vedno CPU čaka...
1. Poglej si ceno FPGAja, ki ima PCIe vmesnik. Jaz sem našel samo en model, dosegljiv smrtnikom, pa še ta je imel jako kilavo vsebino. Močni Virtex modeli komot stanejo tolk ko avto.
2. Zakaj bi kupoval karkoli, če imaš neprimerljivo močnejši HW že v plati ? Pa ne samov plati ampak VDELAN v Northbridge.
Imaš kako boljšo idejo kako bi stvar delala na vsem hardwareu ki ga imam jaz med staro šaro?
če gre za stvari, ki imajo dokumented register set in dober OS driver, potem ja.
Če tega ni, potem ne. Ampak v tem primeru itak ne boš imel lean and mean kernela, ker bo v enem znatnem ( sicer resda zunanjem modulu) črna škatla, o katere notranjosti ne veš nič.
Naj te spomnim, noben računalnik iz moje stare šare nima AGP slota.
Mnogi Diamondi in podobne zadeve so bili PCI, pa so imeli kojekakve pospeševalnike in bližnjice. In če se prav spomnim, tem zadevam bi ti rad vdahnil novo življenje. To pa najbrž pomeni polaganje v ovinke, torej...
On the journey of life, I chose the psycho path.
Tutankhamun ::
Če jaz v Cju sploh ne morem narest tistega kar sem si jaz zamislil ne bodo razlike prav nič marginalne. Tudi pri času ne bom prišparal če rabim delat kroge okrog tistega kar hočem narest. Primer: hočem flipnit en bit v CPU:
ASM:
mov eax,cr0
or al,1
mov cr0,eax
C:
Čira čara, 50 vrstic includov, če se sploh da.
V Cju ni prov nobenih includov za flipanje:
spremenljivka ^= 1; // flipneš prvi bit
spremenljivka ^= 4; // flipneš 3 bit
Slab primer si dau...
Drgač pa komi čakam, da kej nardite. Sm tut sam mau razmišlu v tej smeri kot vi, pa se mi samemu ni dal tega delat. Sm pa na PICu naredu en tak bogi mičken OSek :P. Znau je poganjat max 14 procesov, pa usak je meu mislm da 128 bajtov memorije, ki jih je lahko uporabu... :P. Uglavnem je blo tko da je en procesek komuniciru prek RS232 drugi je skrbeu za prikaz na LCD, tretji pa tipkovno čekiru. Pa je prov fajn delal.
AMD Phenom QUAD 9950 Black Edition, 8GB
Brane2 ::
On je flipnil bit v namenskem CR0 registru, ki ga ti v userland kodi ne vidiš.
Čeprav mislim da definicija ustreznih makrojev za take zadeve sploh ne bi smela biti problem.
Če že ti registri niso definirani kar v samem modelu CPUja...
Čeprav mislim da definicija ustreznih makrojev za take zadeve sploh ne bi smela biti problem.
Če že ti registri niso definirani kar v samem modelu CPUja...
On the journey of life, I chose the psycho path.
DustWolf ::
V Cju ni prov nobenih includov za flipanje:
spremenljivka ^= 1; // flipneš prvi bit
spremenljivka ^= 4; // flipneš 3 bit
Slab primer si dau...
Če bolje pogledaš boš videl da sem flipnil bit v registru cr0, kontrolem registru, ki v Cju ni tako simple dostopen. Ali pač?
Drgač pa komi čakam, da kej nardite. Sm tut sam mau razmišlu v tej smeri kot vi, pa se mi samemu ni dal tega delat.
Nam tudi ne zato iščemo dodatne.. ;) No, saj vsak naredi nekaj potem pa daš skupaj in združiš kodo.
Sm pa na PICu naredu en tak bogi mičken OSek :P. Znau je poganjat max 14 procesov, pa usak je meu mislm da 128 bajtov memorije, ki jih je lahko uporabu... :P. Uglavnem je blo tko da je en procesek komuniciru prek RS232 drugi je skrbeu za prikaz na LCD, tretji pa tipkovno čekiru. Pa je prov fajn delal.
Zveni zabavno.
Sicer na PC platformi, bi jaz to naredu z ISRji... in potem ne rabiš pravega multitasking okolja (nekega timer ISR hooka ki bi switchal med procesi z tlačenjem offsetov na stack), ampak ko pa hočeš narest da dejansko dve aplikaciji sočasno delata, taki ki nimata nobene neposredne zveze z strojno opremo (ala notepad) potem je pa treba razmišljat o CPU schedulerju... no ampak saj še nismo tam. :)
Problem je nekako v tem ko si stvar v glavi tako lepo razdeliš, na cpu scheduler, na memory managment, itd, potem ko moraš pa napisat je treba pa vse sočasno ker je vsaka komponenta odvisna od ostalih in brez njih ne dela... ti kar voljo vzame. :D Ampak saj bo. :)
Brane2 ::
Mene bi zanimal bithreadi ali recimo quadthreadi.
V smislu da povežeš dve jedri, ki sinhrono skočita nekam in začneta izvajat isti thread ali pa vsak svoj subthread, ki sodeluje z "dvojčkom" ali preostalimi tremi "četverčki".
V smislu, da dosežeš efekt blizu temu, kot da nimaš štirih coreov, vsakega s po 3 ALU/FPU enotami ampak enega z dvanajstimi enotami- neke sorte WLIW.
Aja, na i386 to ne pride v poštev, pardon.
V smislu da povežeš dve jedri, ki sinhrono skočita nekam in začneta izvajat isti thread ali pa vsak svoj subthread, ki sodeluje z "dvojčkom" ali preostalimi tremi "četverčki".
V smislu, da dosežeš efekt blizu temu, kot da nimaš štirih coreov, vsakega s po 3 ALU/FPU enotami ampak enega z dvanajstimi enotami- neke sorte WLIW.
Aja, na i386 to ne pride v poštev, pardon.
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
DustWolf ::
V bistvu AFAIK ne. C knjižnica je odgovorna samo za predajo programa in podatkov GPUju in poznejši sprejem rezultatov.
Pri OpenGL.. kolikor sem videl, knjižnjica daje samo iluzijo enotnega vmesnika. Sicer imaš zelo različne hardwareske implementacije... z OpenGL pa lahko driver prosiš da ti pove katere oblike točno grafična kartica podpira... in potem napišeš podporo za tiste implementacije, ki jih boš zahteval.
Linux kernel pa te zadeve prav lepo obvlada. Pač preda podatke zunanji enoti v obdelavo in rezervira therad, ki naj se požene, ko pridejo. V vmesnem času pa počne kaj drugega.
V bistvu se temu da CPU v končni fazi čaka, ko ti izvedeš sam I/O ukaz ne moreš izognit na tak način. Zdaj.. recimo neka implementacija računanja RAID podatkov na grafičnem jedru ne bi predstavljala nekega pripravljanja in čakanja da bo GPU kaj oddelal, da bi imel kaj thread kaj čakat, ampak bi bilo to sprotno pitanje podatkov v jedro in pobiranje rezultatov. Tisto kar sem hotel povedat je da če počneš to, potem ko izvajaš same ukaze za pitanje podatkov v GPU, vsakič ko na procesorju potisneš en podatek nekam, mora CPU počakati da chipset ta ukaz sprejme in ga obdela, kar je (sicer odvisno od implementacije ampak) ne nujno hitrejše od obdelave vseh podatkov v CPU, ker CPU med tem spoon-feedingom skozi FSB ni na voljo za druge ukaze.
1. Poglej si ceno FPGAja, ki ima PCIe vmesnik. Jaz sem našel samo en model, dosegljiv smrtnikom, pa še ta je imel jako kilavo vsebino. Močni Virtex modeli komot stanejo tolk ko avto.
Za razvojni software edino mogoče, sicer recimo Pluto FPGA čipek, stane 32$, kar sploh ni tako grozno, čeprav je res da če bi ga hotel ponucat bi moral ga sam spravit na nek PCI board, in sprogramirat vmesnik.
2. Zakaj bi kupoval karkoli, če imaš neprimerljivo močnejši HW že v plati ? Pa ne samov plati ampak VDELAN v Northbridge.
Mislim da integrirane grafične nimajo kake blazne sposobnosti 3D pospeševanja. Ampak ja recimo, da jaz ponucam mojo 8800 tko še za kak namen. :) Čeprav so se meni zdeli FPGAji bolj zanimivi, ker so pač za točno ta namen, med tem ko GPUji pa pač niso.
če gre za stvari, ki imajo dokumented register set in dober OS driver, potem ja.
Če tega ni, potem ne. Ampak v tem primeru itak ne boš imel lean and mean kernela, ker bo v enem znatnem ( sicer resda zunanjem modulu) črna škatla, o katere notranjosti ne veš nič.
Mislim da meni na čast ne bo šel nihče pisat driverjev. Ne predstavljam pa si kako bi lahko spravil kak obstoječ driver v nekaj za moj namen. Ne planiram namreč enakomernega CPU schedulinga.
LP
DustWolf ::
Mene bi zanimal bithreadi ali recimo quadthreadi.
V smislu da povežeš dve jedri, ki sinhrono skočita nekam in začneta izvajat isti thread ali pa vsak svoj subthread, ki sodeluje z "dvojčkom" ali preostalimi tremi "četverčki".
V smislu, da dosežeš efekt blizu temu, kot da nimaš štirih coreov, vsakega s po 3 ALU/FPU enotami ampak enega z dvanajstimi enotami- neke sorte WLIW.
Aja, na i386 to ne pride v poštev, pardon.
Ne samo i386, ampak a ne bi moral, če bi hotel da nekaj takega deluje, spremenit kar mikrokode same?
Brane2 ::
Pri OpenGL.. kolikor sem videl, knjižnjica daje samo iluzijo enotnega vmesnika. Sicer imaš zelo različne hardwareske implementacije... z OpenGL pa lahko driver prosiš da ti pove katere oblike točno grafična kartica podpira... in potem napišeš odporo za tiste implementacije, ki jih boš zahteval.
Poglej si, kako dela nVidijina CUDA. Stvar uporablja dva compilerja- gcc za CPU in nvcc za GPU. Končni rezultat je program, ki na tvojem CPUju samo uploada kodo C funkcije. Isotimena stub funkcija, ki jo pokličeš, poskrbi za to, da skopira dane ji podatke v GPPU RAM in ti vrne rezultat GPUja, ko je funkcije konec.
V bistvu se temu da CPU v končni fazi čaka, ko ti izvedeš sam I/O ukaz ne moreš izognit na tak način. Zdaj.. recimo neka implementacija računanja RAID podatkov na grafičnem jedru ne bi predstavljala nekega pripravljanja in čakanja da bo GPU kaj oddelal, da bi imel kaj thread kaj čakat, ampak bi bilo to sprotno pitanje podatkov v jedro in pobiranje rezultatov. Tisto kar sem hotel povedat je da če počneš to, potem ko izvajaš same ukaze za pitanje podatkov v GPU, vsakič ko na procesorju potisneš en podatek nekam, mora CPU počakati da chipset ta ukaz sprejme in ga obdela, kar je (sicer odvisno od implementacije ampak) ne nujno hitrejše od obdelave vseh podatkov v CPU, ker CPU med tem spoon-feedingom skozi FSB ni na voljo za druge ukaze.
AFAIK te stvari pičijo skozi DMA. Še več, kartica je lahko master pri prenosu in če je treba, sama skopira podatke v CPU ram in po potrebi tudi generira interrupt, ko je naloge konec.
Za razvojni software edino mogoče, sicer recimo Pluto FPGA čipek, stane 32$, kar sploh ni tako grozno, čeprav je res da če bi ga hotel ponucat bi moral ga sam spravit na nek PCI board, in sprogramirat vmesnik.
Z implementacijo PCIja so se hvalili proizvajalci FPGAjev mogoče 10 let nazaj, sedaj pa sodi bolj v pi**kin dim dosežke.
Še vedno boš mogoče našel čipe, ki imajo probleme s power-up zahtevami PCI spec ( taprvi Xilinxi so mislim da sodili v to skupino), ne pa s samimi timingi.
Hitri serijski linki so pa povsem druga stvar.
Boardi, ki si jih linkal, niso v ničemer posebni. Osebno mam mogoče raje Xilinxov razvojni board s Spartanom.
Kot rečeno, govora je bilo o PCIe in ne o PCI specsih, ki so itak za na odpad.
Najdi mi najcenejši PCIe FPGA čip, pa lahko kaj rečemo naprej. Kot rečeno, jaz sem našel samo par modelov pri Actelu.
Tako Xilinx kot Altera imata to samo v premium čipih, ki pa stanejo.
Mislim da integrirane grafične nimajo kake blazne sposobnosti 3D pospeševanja.
Saj je ne rabim. To, kar imajo, je povsem zadosti. Pravzaprav veliko več, kot rabiš. Že zato, ker stojijo na poti pretakanja podatkov in ker razbremenjujejo CPU, ki zaradi svojih kompliciranih struktur ni ravno blesteč pri hitrem switchanju taskov.
Ampak ja recimo, da jaz ponucam mojo 8800 tko še za kak namen. :) Čeprav so se meni zdeli FPGAji bolj zanimivi, ker so pač za točno ta namen, med tem ko GPUji pa pač niso.
To ni čisto res. GPUji so programmable že kar nekaj časa, in vse bolj bodo. Poleg tega so hitri ( rad bi videl FPGA, na katerem implementacija GPU doseže 500 MHz) , res veliki ( kje boš dobil FPGA z 320x 4 x 64 bitnimi ALU enotami ?), malo porabijo ( poglej si porabo enega močnega Virtexa, ko piči s polno paro ) in malo stanejo ( za ceno enega takega Virtexa dobiš lopato GPUjev).
Mislim da meni na čast ne bo šel nihče pisat driverjev. Ne predstavljam pa si kako bi lahko spravil kak obstoječ driver v nekaj za moj namen. Ne planiram namreč enakomernega CPU schedulinga.
Saj to sprašujem. Eden od selling pointov te implementacije je bil zanesljivost, ker da ti natanko poznaš svojo kodo.
Kar ne velja, če imaš zunanje closed-source binary blob-e.
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
Brane2 ::
Mene bi zanimal bithreadi ali recimo quadthreadi.
V smislu da povežeš dve jedri, ki sinhrono skočita nekam in začneta izvajat isti thread ali pa vsak svoj subthread, ki sodeluje z "dvojčkom" ali preostalimi tremi "četverčki".
V smislu, da dosežeš efekt blizu temu, kot da nimaš štirih coreov, vsakega s po 3 ALU/FPU enotami ampak enega z dvanajstimi enotami- neke sorte WLIW.
Aja, na i386 to ne pride v poštev, pardon.
Ne samo i386, ampak a ne bi moral, če bi hotel da nekaj takega deluje, spremenit kar mikrokode same?
Ne bom trdil 100% ampak IMHO ne. Polovički v recimo AMD64 X2 sta povezani preko internega switcha, če se ne motim.
Kar pomeni, da tudi če ne moreš potegnit kakega posebnega trika ( recimo kak cacheline v L2 uporabit kot interni SRAM ), si lahko CPUja pošiljata podatke preko nekega področja v RAMu, kjer podatek niti ni nujno za potrebe programa da kdajkoli zapusti CPU in živi samo v L2.
CPU0 skoči v svoj thread, CPU1 pa v "dvojčka". Threada se preko omenjene komunikacije sinhronizirata, nato pa opravita svoje...
On the journey of life, I chose the psycho path.
Senitel ::
To ni čisto res. GPUji so programmable že kar nekaj časa, in vse bolj bodo. Poleg tega so hitri ( rad bi videl FPGA, na katerem implementacija GPU doseže 500 MHz) , res veliki ( kje boš dobil FPGA z 320x 4 x 64 bitnimi ALU enotami ?), malo porabijo ( poglej si porabo enega močnega Virtexa, ko piči s polno paro ) in malo stanejo ( za ceno enega takega Virtexa dobiš lopato GPUjev).
Saj vem da bo tole izpadlo malo... Ampak ALU-jev si kar precej preveč naklofal. Radeon 3870 ima 320 32bitnih ALU-jev (64 blokov po 5) in teh 320 32bitnih ALU-jev lahko naredi 64 64bitnih operacij na clock (v bistvu unih 5 32bitnih ALU-jev v bloku naredi eno 64bitno). Radeon 4870 ima pa 800 32bit ALU-jev (160 64bitnih operacij na clock).
GeForce GTX 280 na drugi strani ima 240 32 bitnih ALU-jev in 30 64 bitnih ALU-jev, ampak ne morejo bit v istem ciklu aktivni oboji (interni bandwidth je problem).
Sicer pa čakanje CPU-ja na GPU ne bi smel bit nek hud problem. Imaš DMA, s katerim lahko IO naprava dostopa direktno do rama in tudi GPU lahko v bistvu direktno iz tega rama bere. Vse kar bi CPU počel je sinhronizacija vsakih 64MB recimo...
Brane2 ::
No, zinu sem napamet. Pa zadel velikostni razred. Še vedno precej bolje od FPGAja za ta denar.
Ostal mi je v spominu detajl o 4+1 enoti v AMD bloku in sem pač mislil da govorijo o 320 blokih in ne enotah.
Še vedno je tudi šestnajsinka tega čezinčez zadosti za opisane namene.
Ostal mi je v spominu detajl o 4+1 enoti v AMD bloku in sem pač mislil da govorijo o 320 blokih in ne enotah.
Še vedno je tudi šestnajsinka tega čezinčez zadosti za opisane namene.
On the journey of life, I chose the psycho path.
Brane2 ::
In BTW nekaj sem se poskušal igrat s CUDA-o, pa nikamor prišel.
Najbrž zaradi odsotnosti branja navodil. Se bom še poglobil ( lahko scompilam primere, le pognati jih ne morem - stvar pravi can't run object file )
Se da dobit kaj insajderskih informacij, če je treba proti podpisu kakega NDA, ki ne všteva prenosa pravic nad vitalnimi organi ?
Najbrž zaradi odsotnosti branja navodil. Se bom še poglobil ( lahko scompilam primere, le pognati jih ne morem - stvar pravi can't run object file )
Se da dobit kaj insajderskih informacij, če je treba proti podpisu kakega NDA, ki ne všteva prenosa pravic nad vitalnimi organi ?
On the journey of life, I chose the psycho path.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Ušle specifikacije za Intel MedfieldOddelek: Novice / Procesorji | 10570 (8649) | gendale |
| » | Asambler (asembler)Oddelek: Programiranje | 1255 (1064) | BluPhenix |
| » | NVIDIA gonilnik za LinixOddelek: Operacijski sistemi | 1371 (1242) | borchi |
| » | mikrokontrolerji, programatorji, c/asm ?Oddelek: Elektrotehnika in elektronika | 2984 (2603) | snow |
| » | Rad bi naredil OS. (strani: 1 2 3 4 )Oddelek: Programiranje | 9625 (6597) | Brane2 |