Új üzenet küldése








FUCK SPAM!

TCH
2019.07.09. 21:17:56
10:1 arányban tömörít kicsi CPU igénnyel...ezeket te honnan szeded? Kezdjük azzal, hogy a tömörítés hatékonysága nem csak az algoritmuson múlik, de a tömörítendő adatokon is. Ennek megfelelően generikus 10:1 arányú tömörítő nincs. A column store pedig teljesen más, nem is értem, hogy jön ide, hiszen az egy DB tárolási megközelítés, nem tömörítés.
Ami pedig az interpretált futtatást illeti, az meg tényleg a totál vicc kategória... Szerinted egy interpretált magas szintű kód mikor lesz gyorsabb, mint a gépi? Megmondom: soha a büdös kurwa életben. Az interpretált kód egy-egy elemi utasítása akár több tíz, vagy akár több száz gépi kódú utasításból is állhat. Nincs okos interpreter, ami elég gyorsan fut. Olyan van, hogy JIT, de az pont az, hogy az interpretálandó kódot megfelelteti gépi kódú utasításoknak, tehát ott vagyunk, ahol a part szakad.

Olyat lehet, hogy lecseréled a 16k ROM-ot, de akkor megint eljutottunk oda, hogy bővítünk és akkor meg már miért nem úgy bővítünk, hogy legyen értelme is, csak akkor az éppen már nem Speccy lesz.
E-Mail
Sauron
2019.07.09. 14:51:08
A tomoriteshez egy otlet. Szerintem a legnagyobb elorelepes a programozasban az objektum kod vagy egyenesen interpretalt kod gyors futtatasa. Ha lehetne irni egy ugyes ertelmezot speccyre, ami eleg gyorsan fut (na nem mint a basic) akkor bye bye assembly es a kapott kodot pedig irtozatosan ossze lehet tomoriteni. Szoval mondjuk 16k rom helyett 16k okos.interpreter, es a 48 k ban pedig akar 640 k-nyi tomoritett kod.
E-Mail
Sauron
2019.07.09. 11:42:51
Illetve ne.feledjuk a 16k romot siman felul lehet irni egy kulso megoldassal, es gondolom akar tobb-bel is, szoval akkor az egesz 48k megmarad tomoritett adatnak es programnak.
Volt egy jatek, a Shadow of the Unicorn a Micro Gen tol, ami egy 16k interfeszt tartalmazott pontosan erre a celra. Radugtad a spectrumra, atlapozta a Romot, es kaptal egy 64k jatekot. Csak megjegyzem, beletehettek volna 10 16k romot is, es akkor az mar joval nagyobb, csak nem arra ment a fejlodes.
E-Mail
Sauron
2019.07.09. 11:36:39
A tomoritessel kapcsolatban nem hagyomanyos huffman es tarsaira gondoltam, hanem egeszen masfajta tomoritesre, ami az adatmintakat akar 10:1 aranyban tomoriti igen kicsi cpu igennyel, a kicsomagolas pedig gyakorlatilag nem is nagyon igenyel cput. Ott vannak a column storeok, ezek mind ilyen alapon mukodnek.
E-Mail
Sauron
2019.07.09. 04:58:24
Egyebkent irod video kezeles. En csak szoveges modban gondolkodtam, abbol is meg ablakokban sem, csak ket harom nyavajas terminalablakban.
E-Mail
Sauron
2019.07.09. 04:56:54
Hat igen. Szomoru vagyok. Most egy darabig nem megyek falnak...
E-Mail
TCH
2019.07.09. 00:53:48
Hát azt látom, hogy nagyon makacs vagy. De itt pont egy olyan falat akarsz bezúzni a fejeddel, amit nálad keményebb koponyájúak sem tudnának. 48k-ba szerinted milyen jellegű RAM disket lehetne megvalósítani, úgy, hogy mellette még legyen kernel + videomemória is? Az awk-nak szerinted mennyi funkcionalitását kellene kihajítani, mire a 640 kilójából lemenne kb. 10k környékére, hogy Speccyn is legyen értelme?
Regex match kódot talán lehet írni Speccy-re, de mégis mit kezdesz vele? A regex eszköz és nem cél. A memórialapozás pedig megint az expansion-barrier kérdését feszegeti; ha amúgy is bővítünk, akkor már azt rakunk bele amit akarunk és akkor már semmi köze a Speccyhez. Több Spectrumot ugyan össze lehetne kapcsolni (és írni rá valami iszonyat konvulensen megoldott, több gépre "skálázódó" kernelt), de ehhez megint valami speciális, bővítőportra illeszthető cuccot kéne barkácsolni, mert az nem úgy megy, mint egy parallel vagy serial port, hogy egy kábel is elég.
A tömörítés végképp a vicc kategória. Mármint a kétirányú. Igen, kitömörítőt - mondom: kitömörítőt - van értelme kazettára rakni és mögé felfűzni a tömörített cuccot, aztán kicsomagolni memóriába. De, hogy a memóriában legyen egy kétirányú tömörítő és mellé még kernel, meg FS, meg video, meg terminál, meg még...jóvan, haggyukmá'... (Csak érzékeltetésképpen: a tinfl nevű C-ben írt egyfájlos zlib kitömörítő 10k, míg a miniz nevű zlib ki-be tömörítő 100k. A szerző ugyanaz.)

Azt kéne végre megérteni, hogy bármit is akarunk, kifogyunk a tárból, mielőtt bármit is tennénk. A 48k-s Speccy nem alkalmas arra, amire használni akarod. Ezt a gépet arra találták ki, hogy magnóról betölts egy darab programot - mondom: egy darab programot - és csak azt futtasd.
Persze, lehetne írni hiperprimitív, pár byte-os programokat, meg valami szuperminimál kernelt, ami ezeket futtatni tudja, de ezzel nem érünk semmit. Szerinted mi az oka annak, hogy a SymbOS nincs 48k-s Speccyre, pedig az íróit igazán nem lehet inkompetenciával vagy tunyasággal vádolni? Miért nincs rá CP/M se, miközben Spectrum +3-ra van? Mi az oka annak, hogy nincs egy C64-es GEOS jellegű oprendszer rá? Mindre ugyanaz a válasz: nincs floppy és elég RAM. A floppyt nem tudod megkerülni. RAM-ból is kell legalább 64k (bár inkább több, mert a SymbOS is csak akkor fut a 64k-s modelleken, ha fel vannak bővítve 128k-ra, a GEOS meg ugye úgy futott C64-en, hogy a fájlrendszer egy bitet nem vett el a memóriából, mert az a lemezegységben volt külön). De Spectrum 48k-n nincs se floppy se elég RAM. Ennek megfelelően egyszerűen nem lehet rá használható - mondom: használható - rendszert összehozni. Minimálszart, ami nem jó semmire, azt igen. De annak mi értelme?

Sz*rk: Alámposztoltál, de igazából erre a Hurd-os posztra is vonatkozik a második bekezdés.
E-Mail
Sauron
2019.07.09. 00:36:09
Kicsit mas tema de megis idevag egy kicsit. Olvastam kijott a hurd uj verzioja. Nem vagyok koszonoviszonyban sem a hurddal de.irjak, hogy egesz mas a tervezesi filozofiaja mint a linuxe, mikrokernel, ami csak alap kommunikaciora fokuszal a harverrel, minden mas extra, tul keppen egy applikacio. Szoval ez alapjan lebetne dolgokat spectrumon is irni kicsiben, es mindent behuzunk es csak azt, ami kell.

Edit History Source ?Discussion
Welcome to... ... the GNU Hurd!

Home
Community
Contact Us
Donate
Contributing
Public Hurd Boxen
QEMU Images
Getting Help
Project Ideas
Open Issues
Documentation
FAQ
Hurd
Documentation
Running
Mach
Documentation
GNU Mach
MIG
Documentation
GNU MIG
Debian GNU/Hurd
GNU System
Hurd NG
A Microkernel has nothing to do with the size of the kernel. Rather, it refers to the functionality that the kernel provides. It is generally agreed that this is; a set of interfaces to allow processes to communicate and a way to talk to the hardware. Software drivers, as we like to call them, are then implemented in user space as servers. The most obvious examples of these are the TCP/IP stack, the ext2 filesystem and NFS. In the case of the Hurd, users now have access to functionality that, in a monolithic kernel, they could never use, but now, because the server runs in user space as the user that started it, they may, for instance, mount an FTP filesystem in their home directory.
E-Mail
Sauron
2019.07.09. 00:08:58
Csak... en nagyon makacs embernek szulettem. Ami az evek alatt alabbhagyott, mert sokszor jobban fajt a fal, amin at akartam torni, mint amit elkepzeltem elore...
Szoval gondolkodjunk pusztan elvi szinten es maradjunk kicsik. A fajlrendszert en nem banom egyaltalan, ha a memoriaban letezik csak elsosorban. A sed awk es tarsai nem ugy kene ezek alapjan elkepzelni, ahogy vannak, vagy ahogy megszulettek, hanem alkotoelemeikre bontva megprobalni kifoguralni hogy mikent lehet pl alap regex et par kilobajtban megcsinalni. A C kodja ha jol emlekszem nem tobb par oldalnal. Ha tevedek, akkor.kicsit tovabbi egyszerusitesek kellenek illetve ujrairasok, mert hat ki mondja, hogt a regex forras ami rendelkezeare all a legjobb? Addig van legjobb, amig jobbst nem irunk helyette. Vagy en, vagy Te, vagy mas.
Szoval nekem az tok eleg hogy nehany funkcio elmuzsikal alacsony szinten a memoriaval. Ebbe mar kicsi, de pelda erteku peldak belefernek es oktatasra pl tok jo lehet.
Mellette a memoria lapozas nem egy nagy ugy, bar nem tetszik de a kenyszer ravihet. Vagy ket harom spectrum osszekapcsolasa se a pokolbol valo otlet, ami megint megnyithat bizonyos tavlatokat.
De a legfontosabb szerintem, mint mindig, a technika. Alap file rendszer es navigacio, es nehany utility amit be kell huzni kazirol vagy mashonnan, hogy mukodjon. Illetve fuknciokat is ossze lehetnw allitani es betolteni, linkelni specifikusan a feladatra mert mindek is kene nekem awk szubrutin mikor csak par ciklust akarok futtatni egy par text fileon vagy egyszeru kepanyagon?
Illetve az egesz tar alapbol tomoritve lehetne legalabbis ahol ez kifozetodo ami tobbnyire az adat. Es az adat ae ugy legyen tarolva mint egy brutal buta fat vagy ntsc vagy ext3 ban, hanem meretre optimalizalva mint stacker, jam voltak anno, de lehet abbol is ujat irni es a par szaz k adatbol maris lehet 20k.
E-Mail
TCH
2019.07.08. 22:44:03
Kezdjük azzal, hogy a "natúr" 48k-s Speccy-n nincs értelme a fájlrendszernek, mert az egyetlen "háttértár", amit rá lehet dugni, az a tape. A tape pedig szekvenciális hozzáférésű és nem random. És teljesen mindegy, hogy MP3 lejátszót dugsz rá, vagy eredeti szalagos magnót, mert a szekvenciális hozzáférés marad. Bővíteni persze lehet mindenféle kütyüvel, de ha már bővítjük, akkor már ennyi erővel rá lehet dugni egy Z80000-es "turbókártyát", aztán annyi. De abban mi a Speccy? Nem. A minimum hardware egy bármilyen fájlrendszer alá az olyan, aminek van véletlen elérésű tára. Ennek megfelelően az egyetlen stock modell, ami szóbajöhet, az a ZX Spectrum +3. Valószínűleg ez az egyik oka, hogy a SymbOS nincs original Speccyre. Aztán, valami egyszerű shell-t, meg primitív fájlrendszert persze lehetne írni egy floppy-val bíró gépre, de ahhoz azért nem ártana, ha lenne elég RAM is. Csak emlékeztetőül: C64-en sincs "fájlrendszer", mert ott a DOS a lemezegységben van és van benne külön RAM, meg CPU. Ennek megfelelően egy 48k-s gépen, ahol még a képernyőmemória is lejön a tárból, nem nagyon van esélye normális rendszert felépíteni. Valószínűleg ez a másik oka, hogy a SymbOS nincs original Speccyre.

A dolog második részét viszont, hogy az awk-ot, sed-et, vagy bármi hasonló eszközt te egy ZX Spectrum 48-asra portolj, az megint a sok sikert hozzá kategória. Az utóbbi "csak" ~100k Linuxon, viszont az előbbi az olyan laza 640k; még az MS-DOS-nak is megfeküdné a gyomrát. És megint, ezek az eszközök egy csomó dologban függenek a libc-től, a kerneltől, meg egyéb dolgoktól. Ez még 128k-ban is sok lenne. És ezen nem segítene semmiféle screen-split trükk.
E-Mail
Sauron
2019.07.08. 20:44:08
Peldaul. Annak idejen szorakoztam az Euphoria nevu nyelvvel. Iszonyu egyszeru, es emellett teljes grafikus sdk ja van a windowshoz. Szoval gyorsan lehetett vele valami latvanyosat osszehozni. A problemam az volt, hogy oktatoprogit talaljak ami mutatja es begyakoroltatja.bizonyos parancsok mukodeset egy eleg nagy klaszteres linux kornyezetben. Az egesz kornyezet tul draga lett volna beallitani, de egy.ugyes.kis szimulatorral akarmi bemutathato. Szoval ez.volt a cel es egesz.jo lett, bar befejezni igazan nem tudyam, mas prioritasok miatt.

Most a spectrumon hasonloban gondolkodnek, csinalni egy nagyon kicsi (ertsd leegyszerusitett es kis lenyomatu) csonkot, ami pl egyszeru file kezelest mutat be. Listazhatod a filejaidat, valthatsz direktorit, belenezhetsz egy.ket fileba. Mindezt egy, vagy akarhany terminal ablakban. Max fileok 100,.max direktori melyseg 3,.max file hossz mondjuk 100 byte. Ez ha megvan, akkor tovabb lepni sort, regex, awk sed stb eszkozokre.
Mas prpjekt lenne a megoldas Nagyitasa, optimalizalasa. Pl 48kban nagyok q korlatok, de 80 vagy 128kban mar kisebbwk. Ha bedugsz egy microdriveot vagy floppit, neadj isten kazettas.magnot, akkor megno a hatterter. Kaz magno lehet bluetoothos mp3 olvaso is, mert mar van ilyen. Ez.mar kicsor tul megy az eredeti speccyn de akkor emulatorban, a nagyitas reszekent jelenhetne meg.
De kicsinek maradni is oriasi, sztem miutan a spectrum screen 3 reszre oszlik, a felso kettot elvesszuk, oda toltunk progit, alson meg 2 vsgy 3 terminal ablakot, es ott marad 42k memoria adatnak, es.overlay funkcipknak. Talan nem lenne lehetetlen?
E-Mail
Sauron
2019.07.08. 20:30:57
Ja,.hat engem maga a feladat is erdekel, talan jobban is, mint a vegtermek. Szoval pl ott egy jo pelda, amit irtal. Ls es filerendszer. Hogy lehetne ilyesmit speccyn megvalositani? Szerintem tobbfelekeppen, es mindenkeppen ujszeru,.ordogien egyedi megoldasokkal. Pl . Mondjuk eloszor is meghatarozzuk,.hogy mi az a minimum ami kene, mire lenne ez.jo, es kb mi a realitasa, kovetwlmenyei. Ha ez.megvan, akkor ennek alap reszeit ki lehetne dolgozni szerintem, majd iterativan optimalizalni.
E-Mail
TCH
2019.07.08. 15:38:25
windows 95: minimum 386sx (32-bites CPU) és 4 MB RAM, windows nt3.1: minimum 386dx (32-bites CPU) és 12 MB RAM, MS-DOS 5.0: minimum 286 (16-bites CPU) és 384 kB RAM. Hogy jött ez ide? Még mindig Linuxos szarok Z80-ra való portolásáról beszélünk és nem arról, hogy mit lehet egy régi 32-bites CPU-ra átírni. És azonfelül az egyes parancsprogramok kódjának portolása önmagában kevés, mert az ugyan lehet, hogy pl. az ls maga a parancs még Z80-on is futhatna, de mi lesz azokkal a dolgokkal, amikre szüksége van, pl. a fájlrendszer, meg a kernel? Scriptingről, meg terminálemulációról nem is beszélve.
E-Mail
Sauron
2019.07.08. 14:39:55
Miert ne? Ott vannak a unix utils dosra meg windowsra, egesz 90tol. Semmi multitask, csak a utilityk.
E-Mail
TCH
2019.07.08. 13:18:42
Z80-ra semmiféle Linuxos dolgot nem tudsz portolni, még a legapróbbat sem.
E-Mail
Sauron
2019.07.08. 02:32:11
Vilagos. Erdekes lehetne, hogy csak nehany dolgot megoldani. Pl terminalok fussanak egyszerre es linuxos parancsok, scripting. Szoval nem mindent, de valamit.
E-Mail
TCH
2019.07.07. 23:10:01
Nekem is tetszik. De ettől még egy modern oprendszert nem lehet Z80-asra portolni. És ez nem tunyaság kérdése.
E-Mail
Sauron
2019.07.07. 23:06:19
Oke! Lenyeg, hogy tetszik. Nekem nagyon :)
Az a komment az interjubol van, csak ramutat, miert is jo ez az egesz retro dolog. Emlekeztet, hogy mashogy is lehet alkotni.
E-Mail
TCH
2019.07.07. 18:59:35
Nem mondtam, hogy nem jó. Azt mondtam, hogy nettó ökörség a Linuxhoz hasonlítani. Leírták, mit értenek preemptíven:
For the task management a combination of pre-emptive and cooperative multitasking has been choosed, which makes different task priorities possible. Pre-emptive means that tasks are interrupted after a certain amount of time by the operating system, in order to share the CPU time with other tasks. Cooperatively means, that a task stops using CPU time by itself. It does it, if it finished its current job or is waiting for a certain event. Because of this combination it is possible to assign priorities. Tasks with a low priority receive CPU time only if all tasks with higher priorities are not currently working.
Magyarán van lehetőség preemptive módon futtatni programot, de cooperative módon is. Viszont akkor lehet rajta olyan cooperative módon futó programot írni, ami sose adja vissza a vezérlést a rendszernek.

A win95 meg egy gigászi szarrakás volt, preemptive my ass, CLI HLT FTW.

Az tény, hogy sok lusta balfasz van a szakmában, aki pazarolja az erőforrásokat, csak nem tudom hogy jön ide, a Linux@Z80 témához.
E-Mail
Sauron
2019.07.07. 15:50:07
Ez a megjegyzese telitalalat a mai programozok tunyasagarol

Todays computers are so fast, that you usually don’t recognize, if your code is completely unoptimized. If it’s running on your local machine only, that maybe ok, so there is no pressure to learn it anyway.
E-Mail
Sauron
2019.07.07. 15:32:02
Itt meg a megalkotoja irja, hogy az alap spectrumra lehetetlen, de a 128k ra megoldhato lenne.

https://distritoentebras.wordpress.com/2017/12/23/interviewing-jorn-mika-aka-prodatron-symbos-creator-and-retro-enthusiast/
E-Mail
Sauron
2019.07.07. 15:22:45
Itt kolteszkednek rola, hogy preemptiv is, csak nem annyira stabil: https://www.cpcwiki.eu/index.php/SymbOS

"While the MOS Technology 6502 can not move the stack, the Z80 can freely replace it to any position in the memory, which is more or less a condition for pre-emptive multitasking."

Ha win95 nel stabilabb akkor mar tok jo. Nekem jol mukodott a win95 is, megfelelo patchek es hozzaallas tudataban.

E-Mail
Sauron
2019.07.07. 15:10:36
Az attol meg tok jo is lehet. Csak az faj, hogy nincs Spectrumra vagy zx81re.
De a preemptivitason akkor mit erthetnek?
"it is based on a microkernel, which provides preemptive and priority-oriented multitasking "
E-Mail
TCH
2019.07.07. 14:06:16
Ja. Cooperaitve multitaskingot. Merthogy ez is az. A grafikus felülete meg kb. a GEM-mel egyszintű, vagy lehet, hogy valamivel jobb. És az egyes verziói direkt az egyes gépekre vannak optimalizálva. Pontosan azt tudja, amiket én itt az előző posztokban felsoroltam, hogy mit tudhat egy 8-bites gépre írt multitask oprendszer és köze nincs a Linux funkcionalitásához, amiről te beszéltél, hogy portoljunk egy lecsupaszított Linuxot Z80-ra.
E-Mail
Sauron
2019.07.07. 12:42:52
Ugy tunik mas is almodott mar multitasking ot z80-on: https://en.m.wikipedia.org/wiki/SymbOS
E-Mail