Gépi kódot generáló DOS compiler?

Gépi kódot generáló DOS compiler?
2012-04-21T12:20:53+02:00
2012-04-27T19:06:10+02:00
2022-10-25T09:00:35+02:00
  • És legfőképpen, ki az a Szabó Attila?

    Na nehogy már közületek egy se ismerje Szabó Attilát!

    KÖMAL, országos matekversenyek, nemzetközi fizikaversenyek... egyikről sem rémlik ???
    Mutasd a teljes hozzászólást!
  • Megírod az első assambler/dissasambler programodat hexában


    Ja, hexeditorban aztán meg pláne meg tudnám csinálni...


    Egyébként meg azért vagyok megszállott, mert egyszerűen megszállott vagyok... ez van, a floppy-s korszak óta. És nem nagyon tudom levetkőzni, bocs.
    Egyszerűen ezt szoktam meg : kis méret, optimalizált gépi kód, és akkor nyugszom meg - az más kérdés, hogy ennek ellent mond, hogy nem vagyok hajlandó megtanulni assembly-ben.. vagy inkább én azt mondanám, hogy nincs is annyi időm rá, meg nem akarok úgymond "kockáztatni".
    Tudom, rossz megröggzöttség. Bocs.

    Egyébként meg a felhasználók még mindig azt várják el a programozótól, hogy minél kisebb legyen a program, azt már nem kérdezik, hogy azt hogyan lehet, illetve mennyire nehéz méretre optimalizálni
    Mutasd a teljes hozzászólást!
  • Alapvetően azért, mert minden programnál vannak dolgok amik előfordulnak, és amit - pont azért, hogy kisebb legyen a kód - nem írnak le 25 ezerszer, hanem beleteszik abba a kódba ami mindig hozzá fordul az exe-dhez. Aztán, ahogy a progik egyre komplexebbek lesznek, vannak különféle könytárak, ezeket vagy statikusan hozzálinkelik az exe-dhez, vagy kiteszik egy dll-be amit meghívhatsz - és amit szintén telepítened kell. Vagy előre telepítik az end-user gépére, lásd windows dll-ek vagy a .NET.

    Ettől független az, hogy a kódod mennyit nő attól, hogy beleírsz egy adott kifejezést a kódba. Persze, a helló világnál számít, hogy mekkora az exe induló mérete (már akinek), de egy komplexebb program esetén egyre kevésbé. És a mai cuccokat nem a helló világra optimalizálták, valahol érthető módon: viszonylag kevés az olyan felhasználó aki egész nap helló világot akar futtatni. És azokat is milyen ritkán engedik ki a zárt osztályról! Így a helló világ piaci részesedése viszonylag csekély, ezért aztán a fejlesztők nem erre koncentrálnak.

    A dolog másik oldala, hogy a memória ma nagyjából huszadrangú kérdés. Ma nem 30 éve van, amikor az 1 kilobyte-os ZX-81 volt a divat. És már a DOS-os időkben is volt olyan, hogy a fordító megkérdezte, hogy sebességre vagy méretre optimalizáljon. Ma, amikor a memóriához képest a kódod mérete elhanyagolható, a sebesség a default. Egy százezer soros progit is meg tudsz írni úgy, hogy max pár mega lesz a kódod mérete, miközben egy vacak mobilefon 512MB körül kezdődik.
    Mutasd a teljes hozzászólást!
  • A 3.5 verzió minden win7 alapú gépen rajta van. Az XP napjai pedig meg vannak számlálva. És, bár egy profi assembly fejlesztőnél rosszabb kódot generál - de nagyobb progi esetén nálad biztosan jobbat.
    Mutasd a teljes hozzászólást!
  • "Mellesleg a MicroBasic-hez azt írta a készítője, hogy 4 nap alatt írta meg, amit még abban az esetben is furcsállanék, ha éjjel-nappal, szó szerint 24 órában ott ült volna a gép előtt"


    Szerintem meg lehet 4 nap alatt írni egy fordítót valamilyen egyszerűbb nyelvhez. Igazából ha nem kötöd ki hogyan nézzen ki, csak hogy legyen turing-teljes és akár virtuális gépen is futhat, akkor én is megírok neked egyet 4 nap alatt szerintem (prognyelvek3 beadandónak úgyis kéne írni majd valamit, kacérkodok ilyesmivel) :)

    Persze normális fordítót, ami gépi kódra fordít és valami legalább programozói ergonómiát is szem előtt tartó szokványos nyelvtannal is rendelkezik (+szemantikával), na olyat már nem annyira triviális írni és olyat pedig ami optimalizál, típust vezet le, objektumorientált meg hasonlók pedig már végképp nem.
    Én valamikor azért mindenképpen akarok egy normális saját nyelvet működő fordítóval. A nyelvből sok dolog már papíron meg van egyébként és szerintem még 1-2 versenyképes ötlet is van köztük amúgy.

    ui.: Azt én se értem mi ez a mánia ami neked van, pedig én is elég lowlevel figura vagyok/voltam. Mindenesetre mi lenne, ha feltennéd a bare metal oprendszert valahova a gépedre? Egy ismerősöm is írt pár dolgot a C-fordítójukhoz (nem magába a fordítóba, de a library-k saját megvalósításába) és ez egy olyan rendszer, hogy ha akarsz ott csavargathatod kézzel a biteket, ahol szeretnéd, egyszerre pedig egy taszk fut csak igazán (bár védett módban). Mint mondtam, van hozzá valami C-fordító is, bár nem tudom mennyire "pró".
    Mutasd a teljes hozzászólást!
  • hivatkozásokat rak be a programba a Windows rendszerről


    Megteheted, hogy a szükséges rutinokat újra implementálod (értelme ugyan nem sok van). A WinE forrása segítségedre lehet ennek megvalósításában. Amúgy meg pl. a
    Norton Ghost
    boot CD-je tartalmaz egy viszonylag "lebutított" Windows-t. Így csak azt kellett külön megvalósítani, hogy ez az egyszerűsített rendszer sikeresen betöltődjön. A Windows alá fordított alkalmazás mindaddig vígan fut rajta, amíg nem akarsz olyan szolgáltatást, ami ebben a környezetben nem áll rendelkezésre. Ezt a módszert egyébként több terméknél is alkalmazzák. A kérdés inkább az erre vonatkozó licensz...

    ui.: ennél már jóval egyszerűbb, ha betöltesz pl. valamilyen
    free DOS
    -t és a boot folyamatába (autoexec.bat) beiktatod a saját kis DOS-os alkalmazásodat... így megoldhatod ez egészet, akár 1 MByte alatt is, ami manapság nevetségesen kicsinek számít.
    Mutasd a teljes hozzászólást!
  • Szabó Attila a 90-es években a Katona József színház gazdasági igazgatója volt. Látod? Csak eszembe jutott...
    Bár, ő nem az a híres Szabó Attila akire NevemTeve gondolt, hanem egy másik híres Szabó Attila.
    Mutasd a teljes hozzászólást!
  • Hogyne tudnánk, ki volt a Süsü rendezője!
    Szabó Attila
    Mutasd a teljes hozzászólást!
  • És legfőképpen, ki az a Szabó Attila?


    Azért ez ciki egy szakmai forumon.
    Nem tudod ki A Szabó Attila?
    Szégyenlem magam helyetted.

    Mutasd a teljes hozzászólást!
  • Szerintem valami harminc évvel ezelőtti könyv/cikk akadt a kezébe, annak alapján akar eligazodni a jelenben.
    Mutasd a teljes hozzászólást!
  • Aha... Lehet.
    És minek akar optimalizálni aki még a szakkifejezéseket se ismeri?
    "
    90 parancs
    " Nem tudtam sírjak vagy nevessek... (a tanácstalan szmájlit nem találtam)
    Mutasd a teljes hozzászólást!
  • (Szerintem önmaga, ha ennyire fényezi)
    Mutasd a teljes hozzászólást!
  • Mire fel ez az optimalizálási mizéria? Mintha C=64-re akarnál fejleszteni...
    És legfőképpen, ki az a Szabó Attila?
    Mutasd a teljes hozzászólást!
  • És ez egyébként is egy paradoxon mondat. Ha nem értek az assembly-hez, márpedig valószínű hogy egyetem előtt - ahol már valsz. kötelezni fognak erre - nem fogok assembly-t tanulni, akkor nem is fogok tudni sehogyan sem nekilátni egy fordító megírásának.


    Nem paradox, mert keresel egy megfelelő processzor referenciát. Megírod az első assambler/dissasambler programodat hexában: dissasambly, save, load, edit. Utána szépen fejleszted tovább önmagában.

    De inkább ennek néznék utána, a Rust-ot is ezzel készítették:
    LLVM: Low Level Virtual Machine
    Mutasd a teljes hozzászólást!
  • Mert én eddig úgy láttam, hogy a legtöbb fordító úgy építi fel az EXE-it, hogy vagy hivatkozásokat rak be a programba a Windows rendszerről


    Hát ezt nehéz elkerülni, mivel egy modern oprendszer nem enged közvetlen hozzáférést a külvilághoz. Ha ablakot akarsz nyitni, az oprendszert kell kérned. Ha fájlokat akarsz megnyitni, megint csak az oprendszert kell kérned. Sőt, ha megnézed a másik topikban az assembly kódomat, még a parancssorod eléréséhez is az oprendszert kell kérned, legalább is Windowson.

    Elvben lehetséges Windows API hívások nélküli Windows programot írni, csak az a külvilágból nem tud se beolvasni, se kiírni semmit, és csak a visszatérési értékét tudja a külvilágnak visszaadni. És talán még ilyenkor is betöltődik hozzá a kernel32.dll, mert az speciális esetnek számít.

    De igazából nem értem ezt a megszállottságodat se a mérettel kapcsolatban, se a Windows kikerülésével kapcsolatban. Pontosan mit is nyersz azzal, ha DOS-ban dolgozol?
    Mutasd a teljes hozzászólást!
  • Én ahogy észrevettem, C# 3.0 fölött (ami min. 2.0-ás NET keretrendszert használ) a legkisebb generálható EXE 2,5 KB-os, és ez ugye fél kilobyte-onként növekszik a forráskód méretének növelésével (úgy vettem észre, hogy a 'using' referenciák is megnövelhetik a program méretét, valamint azt láttam, hogy egynéhány parancs kicsit hosszabb részt tesz ki a fordított exe-ben, mint pl. egy Beep parancs.

    Persze jó az, hogy a .NET-es rövidebb programok jó kicsik ahhoz képest, amilyen felhasználóbarát környezetben és kifejezésekkel megírottak, viszont a nagy hátrány, hogy ugyebár kell a .NET keretrendszer, ami azért kitesz egypár száz MB-ot, és szvsz. nincs annyi gépen rajta alapból, mint ahogy azt állítják.
    Mutasd a teljes hozzászólást!
  • Ha úgy gondolod, hogy ez egy egyszerű munka, akkor nosza! Ha kész vagy, tedd fel a "háló"-ra, hogy más is tudja használni!


    Én nem mondtam és nem is gondoltam ilyesmit! Jól tudom, hogy közel sem tudok és értek olyan jól programozni, hogy ilyesmit csináljak.
    Én csak kiváncsi voltam rá, hogy mik a legfőbb technikai nehézségei egy teljesen gépi kódra fordító program megírásánál.
    Mert én eddig úgy láttam, hogy a legtöbb fordító úgy építi fel az EXE-it, hogy vagy hivatkozásokat rak be a programba a Windows rendszerről, vagy/és egy belső értelmező beírásával teszi tuttathatóvá az EXE-t.

    Ha nem jó az assembly, akkor írj magad egy fordítót.

    És ez egyébként is egy paradoxon mondat. Ha nem értek az assembly-hez, márpedig valószínű hogy egyetem előtt - ahol már valsz. kötelezni fognak erre - nem fogok assembly-t tanulni, akkor nem is fogok tudni sehogyan sem nekilátni egy fordító megírásának.

    (Mellesleg a MicroBasic-hez azt írta a készítője, hogy 4 nap alatt írta meg, amit még abban az esetben is furcsállanék, ha éjjel-nappal, szó szerint 24 órában ott ült volna a gép előtt)
    Mutasd a teljes hozzászólást!
  • hogy egy magas nyelvű fordító teljesen gépi kódot tudjon úgy generálni, hogy ne kelljen magát a fordítót és a parancsok értelmezését/értelmezőjét beleírni a kódba.


    A fordító "magát" azért még nem rakja a kódba.
    Hibakezelést igen, de ez esetenként csökkenthető, kikapcsolható. Durvább esetben még a forráskód egy részét is berakja, így hiba esetén rögtön szól, hogy hanyadik sorban, melyik utasításnál van a hiba.

    Amit még beépít, az külső kódok, Pascal esetén UNIT-ok, az ezekben lévő kódot használja a program (mondjuk ha kiadod a WRITELN utasítást, akkor ennek a kódjának valahol ott kell lennie).
    Másik esetben külső pl. DLL fájlokban lesz a szükséges kód, amit igényelni fog a program, esetleg ezt "nem viszi magával", hanem megköveteli, hogy valahol a Windows-on belül legyen ez meg. Rosszabb esetben nem is a Windows része ez és még külön telepítgetni kell hozzá valamit.

    Ezek mind megkönnyítik a programozó munkáját, valamit spórolnak a kód méretén, esetleg a hordozhatóságot növelik.

    Van olyan, hogy nem kötelező ezeket használni, de van sok nyelv, aminél elkerülhetetlen, mert nincs rá lehetőség, hogy magadnak írj meg valamit.

    Vannak tényleg durva esetek, mikor a "helló világ" program is 1 Megánál kezdődik,vagy egy 20 soros programból 4 Megás EXE-t fordít a fordító.
    Ezeket éppen el lehet kerülni.

    Ezért szeretem a Jávát. Igaz, hogy egy 16 Megás futtató környezetet telepíteni kell hozzá, de utána maga a program nagyon kicsi mint a régi időkben. Ugyanígy látszólag kicsi és gyors a FLASH is.
    IDE-t nem használok, így egy 100K-s szövegszerkesztőben megírok egy rövid kódot, parancssorban fordítom és CSAK a futtatható kód kerül létrehozása (nem lesz mellette több megányi kísérő információ), ami szintén kicsi.

    Feltételezem C#/C/C++ nyelveket használva is el lehet érni hasonló eredményt ami a méretet /sebességet illeti, akár natív kódot használva.
    Mutasd a teljes hozzászólást!
  • miért olyan nehéz technikailag megoldani azt, hogy egy magas nyelvű fordító teljesen gépi kódot tudjon úgy generálni, hogy ne kelljen magát a fordítót és a parancsok értelmezését/értelmezőjét beleírni a kódba


    Nem értem miről beszélsz... Alapvetően a célplatform nem mindegy! Amit pl.
    Intel
    -re írsz (amúgy azok mindegyik fajtája sem feltétlen kompatibilis egymással) az nem igazán fog futni pl.
    ARM
    -on vagy másfajta processzoron. Amit
    DOS
    -alá szán az ember, az meg
    DOS
    nélkül nem fog futni... A fordítókat többnyire általános célra szánják a készítői. Ha nem jó az
    assembly
    , akkor írj magad egy fordítót. Ha úgy gondolod, hogy ez egy egyszerű munka, akkor nosza! Ha kész vagy, tedd fel a "háló"-ra, hogy más is tudja használni!
    Mutasd a teljes hozzászólást!
  • Mondjuk úgy alapból szvsz. tényleg nem. A DOS korban több olyan exe volt - ha jól tudom - ami 32 byte-os fejléccel rendelkezett... az más kérdés, hogy Win7-en még soha nem láttam olyan _futni tudó_ EXE-t, aminek 512 byte-nál kevesebb lett volna a fejléce.

    Old Sharky : figyelj, akkor le tudnád írni, vagy fel tudnád tölteni azt a verzószámot. Egyébként a neten úgy láttam, csak max. 4 verzió érhető le, a 7-es, a 6-os, az 5-ös és a 3.02-es.

    Ivn : Jó, izé, akkor elnézést a hülyeségért amit írtam - legalább a hibáiból is tanul az ember...

    Viszont azt nem tudom, és érdekelne, hogy miért olyan nehéz technikailag megoldani azt, hogy egy magas nyelvű fordító teljesen gépi kódot tudjon úgy generálni, hogy ne kelljen magát a fordítót és a parancsok értelmezését/értelmezőjét beleírni a kódba. ?
    Mutasd a teljes hozzászólást!
  • amiből ha jól rémlik 0,5 Kbyte az EXE fál fejléce


    Ez így nem teljesen igaz...
    EXE Format
    Mutasd a teljes hozzászólást!
  • Bocs, tényleg csak 3,8 Kbyte a "helló világ" a CRT unittal, a legrövidebb program kb. 1,5 Kbyte, amiből ha jól rémlik 0,5 Kbyte az EXE fál fejléce.
    Mutasd a teljes hozzászólást!
  • Mondjuk egy Turbo Pascal programnál egy "helló világ" olyan 20 Kbyte-nál kezdődik...


    Az nem tudom melyik
    Turbo Pascal
    lehetett, de amikkel én találkoztam az kevesebb, mint 2 kByte-ból megoldotta... Ha pl. már a
    Crt unit
    -ot is használatba vettem (amely alapvetően nem szükséges egy "helló világ" szintű programhoz), akkor kb. 3.5 kByte-os méretetű kimenet az eredmény.
    Mutasd a teljes hozzászólást!
  • Miért kell minden hibajelzést is belekompilláltatni egy szegény dos-os programba, amiknek 98 % általában elő se jön, és a juzer szempontjából tökre felesleges, mert úgysem ért hozzá.


    Kicsit el vagy tévedve. Egy magas szintű nyelv nem csak a hibajelzéseket fordítja bele a programba, hanem sok mást, többek közt a "90 parancskészletedet" is. Meg persze memóriakezelő, hibakezelő, és egyéb ilyen általad haszontalannak vélt nyalánkságok.

    Neked nem magas szintű nyelvre van szükséged, ami ismer 90 "parancskészletet", hanem kőkemény assembly fordítóra.

    Persze ott már elveszted a kilobyte-okon spórolt dolgokat, és programozhatsz mindent mnemonic-al, és direktívával. Persze, azzal is megvalósítható, hogy makrók segítségével legyártod magadnak a "90 parancskészletedet".

    amiknek 98 % általában elő se jön, és a juzer szempontjából tökre felesleges, mert úgysem ért hozzá.


    Ez meg egy rossz szemlélet. Láttam már programozót, aki az application.run-t betette egy try-except közé, és roppant boldog volt, hogy az ő programja sose dob nem várt hibaüzenetet.
    Persze az, hogy program helytelenül működött tovább, az már nem zavarta.
    Mutasd a teljes hozzászólást!
  • Gondold el mi történik abban a pár sorban.

    Attól még, hogy leírsz egy sort (println 'hello world'; vagy mi), a háttérben sok száz (ezer) dolog is lefuthat.
    Pl elindul a program, megkapja a windowstol az argumentumokat, valamilyen függvényhívás tuti lesz (println), ezt valahogy a programod átadja az oprendszernek (gondolom winapi), stb.
    Mutasd a teljes hozzászólást!
  • Nem talán Windows Vistán történt ez?


    Nem, XP-n.

    Egyébként tényleg lehet hogy keverem az oprendszer nélkül futó kódot a natív kóddal... már rémlik is, hogy valahol olvastam róla, anno. amikor még naivan azt hittem, hogy képes leszek nekilátni assembly-t tanulni.

    Mondjuk egy Turbo Pascal programnál egy "helló világ" olyan 20 Kbyte-nál kezdődik, ___igaz innen már nem nő olyan mértékben a kód mérete___, így 25-30 Kbyte-ból már szép programot írhatsz...

    jajjj, miért, Istenem miért
    Miért kell minden hibajelzést is belekompilláltatni egy szegény dos-os programba, amiknek 98 % általában elő se jön, és a juzer szempontjából tökre felesleges, mert úgysem ért hozzá.

    Egy hellow binárisan 8 byte (a "helló Wilág" karaktereit nem számolva), egy jóféle TP-nél meg 20 !KILO!byte......
    Jajjjj, Uram-Teremtőm, miért kell mindent túlbonyolítani.

    Na mindegy. Köszönöm még egyszer mindenkinek!!!
    Megyek és letöltöm a TP 3-at.
    Mutasd a teljes hozzászólást!
  • Hali!

    ^^ NEM AZ ÉN HIBÁM ! ^^


    Márpedig de, a te hibád!

    Mutasd a teljes hozzászólást!
  • Itt az ASCII nézetben pl. látszik, hogy az msvcrt.dll-re, és annak néhány belépési pontjára hivatkozik. Tehát ha pl. én ezt egy teljesen lebutított ~28 MB-os Windows-on próbálnám (mert van ilyen WinVerzió ​) akkor el sem indul a
    programom ??


    Lehet ám a C runtime-ot statikusan is linkelni, ha zavar az, hogy egy standard Windows komponenstől függ a kódod. Persze olyan kicsi nem lesz, mint ez a változat...

    Ezenkívül úgy az érdekességképp kedvéért egy ilyen 1,5 Kb-os 'natív' kódba elkezdtem belenyúlkálni. Többek között a sok "félrenyúlásnál" hibajelzéseknél az mscorlib.dll-re, és egyéb dll fájlokra is hivatkozott.


    Nem tudom, ez hogy történhetett meg, mivel a kódodnak köze nincs a .NET-hez.

    viszont egy másik gépen működve már nem adott hangot, nem is várt, de hibajelzést sem adott...


    Nem talán Windows Vistán történt ez, ahol dokumentáltan nincs implementálva ez a funkció?

    Pedig én azt gondolnám, hogy egy tényleg gépi szintű kód ugyanazon típusú Intel x86-os processzorokon ugyanúgy lefut - merthogy azokon, amiken próbáltam, a processzor típusa ugyanazon gyártótól és ugyanazon processzorcsaládba tartozott : Bios-ban megnéztem. A telepített Windows viszont tényleg más állapotban volt mindegyiken...


    Te összekevered a natív kódot az oprendszer nélkül futó kóddal. Nyilván ha az oprendszer szolgáltatásait veszed igénybe, és ráadásul eltérsz a specifikációtól (mert kézzel belepiszkálsz egy binárisba), akkor meglehet, hogy másképp működnek dolgok. De fogadni merek rá, hogy ez a DOS-ban is így volt: ha felraktál egy régebbi DOS-t, ami nem tudta az adott funkciót, akkor nem ment a funkciót használó kód, hiába ugyanaz maradt a vas alatta...

    Mentsétek le Hex-Editorban EXE-be, aztán futtasátok le : Szó szerint hallani fogjátok, hogy mit értek akadozás alatt. Ugyanez Basic-el akadozásmentesen lezavarható lenne.


    Hát gondolom ennek a funkciónak nem a zenelejátszás lenne a rendeltetése. 500ms-es Duration-nél nekem már nem akadozott.
    Mutasd a teljes hozzászólást!
  • Ha jól emlékszem a DOS-os (a DOS/Win9X része) debug.exe programmal is lehet gépi kódú programot írni, majd .COM programként kimenteni.

    Gondolom a legtöbb Assembly fordító is képes (volt) erre.

    Kérdés mennyire akarsz méretre optimalizálni. .COM program esetén pár száz byte-os programot is írhatsz, de ott a 64K-s mérethatár (meg még ki tudja milyen korlátok). Mondjuk egy Turbo Pascal programnál egy "helló világ" olyan 20 Kbyte-nál kezdődik, igaz innen már nem nő olyan mértékben a kód mérete, így 25-30 Kbyte-ból már szép programot írhatsz és nem feltétlenül kell Assemblyvel szórakozni.

    Az is kérdés hogy mit kellene a programnak megvalósítania, mert lehet, hogy eleve DOS alatt nincs rá lehetőség, vagy nagyon nehéz megoldani.
    Mutasd a teljes hozzászólást!
  • nem akarlak megbántani, de az optimalizálás nem úgy működik, hogy "megnyomom a gombot", nyilván egy adott forráskód, meg az adott fordítók alapértelmezett beállításai mellett azért lehet "összehasonlításokat" végezni


    Persze, ezt azért tudom... sose gondolkodtam abban, hogy mindent a géppel csináltassak meg magam helyett.


    Egyébként felőlem akár hanyagolhatnák is a Fortran-t. Egyébként is marhanehéz nyelv, csak azért vetettem fel, hátha abban lenne a megoldás... ..és szerintem is jobb a C.

    Egyébként még a C#-ot is csak tanulom... úgyhogy az Assembly-n és a BrainF**k-on kívül kb. majdnem mindegyikkel ugyanúgy neki kell lássak bíbelődni majd... (na jó, azért ez így nem igaz), és egyébként se akarnék olyan hű-de-profi dolgokat megvalósítani, csak kb. azt a két dolgot, amit leírtam.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd