Gépi kódot generáló DOS compiler?
2012-04-21T12:20:53+02:00
2012-04-27T19:06:10+02:00
2022-07-24T02:52:21+02:00
  • Ja értem. Mondjuk ez meg azt jelenti, hogy nem tudod adott esetben kihasználni a platform extra dolgait, de az nem is feltétlen szükséges a kód nagy részében. Mondjuk az oprendszerhez pont jó lenne, de gondolom ki lehet kerülni ezt a mechanizmust, ha nagyon szeretnéd. (Nem értek az ADA-hoz.)
    Mutasd a teljes hozzászólást!
  • ezek szerint "félreérthető" volt: semmi rendhagyó nincs benne, csak annyi, hogy "teljesen" el van fedve előtted nyelvi szinten a target, és nem egyszerűen arról van szó, hogy más processzorra kell optimalizálnia stb., meg nem arról, hogy a "header fájlok" tele vannak "#if/#ifdef/#if defined/#else/#elif/#endif"/akármivel...
    Mutasd a teljes hozzászólást!
  • azaz esetleg nyugodtan fejleszthetsz a * os alatt alatt a mosógépre/hűtőszekrényre/akármire programot, ez nem magán az Ada programnyelven múlik, hanem az APSE-n, hiszen pont ez volt a nyelv kifejlesztésének egyik célja (a "fejlesztői" és a "futtató platform" "szétválasztása")


    Nem tudom, mi olyan rendhagyó ebben. Egyéb nyelvekre is vannak keresztfordítók, ahol a fordító más platformon fut, mint a lefordított program. (Tehát mondjuk meg lehet csinálni, hogy 32 bites x86-os Windowson fut egy GCC, ami itaniumos Linuxon futó programot generál neked.)
    Mutasd a teljes hozzászólást!
  • "
    ezért csodálkoztam az adán (ha más nem is, hát abban is van new) szóval biztos voltak vele szupások
    "

    szerintem, de lehet, hogy rosszul gondolom/tudom (bár nagyon régen foglalkoztam vele) az Ada-ban pont az az egyik szépség, hogy a host/target teljesen különválik, jobbanmondva ez nem a nyelvnek a sajátja, hanem a "fejlesztői környezetnek", azaz esetleg nyugodtan fejleszthetsz a * os alatt alatt a mosógépre/hűtőszekrényre/akármire programot, ez nem magán az Ada programnyelven múlik, hanem az APSE-n, hiszen pont ez volt a nyelv kifejlesztésének egyik célja (a "fejlesztői" és a "futtató platform" "szétválasztása"),
    gondolom a Java-val is "hasonló" a helyzet, amikor valamilyen nem szokványos rendszerre (azaz nem általános-, hanem célszámítógépre fejlesztenek), leszámítva azt, hogy esetleg abban van a korlátozás, hogy milyen osztályokat stb. használhatsz, de véhetőleg szigorúan nyelvi szinten nincs megkötve a kezed, bár gondolom ott is jvm futtatja a programot és nem natív kódról beszélhetünk, de ez fejlesztői/kódírási szempontból "lényegtelen",
    Mutasd a teljes hozzászólást!
  • Így nyilván lehet csinálni, meg amúgy én is így csinálnám - asm betétek, illetve külön asm-ek - de én olyasmire gondoltam, hogy mixed kód nélkül nem-e lehet... Például TP7-ben volt interrupt kezelés és lehetett portokra is írni, szóval rendszerprogramozáshoz se kellett elvileg asm. Na nem mintha nekem bajom lenne azzal, hogy asm betéteket kell írni

    Ami még érdekes (bár már nem C):
    Itt csinálnak mixed kódban (tehát külső asm-el és asm betéttel) bootloadert. Ami nekem feltűnt az az, hogy ők c++t használnak. Amit művelnek a linken azzal semmi baj nincs, de pl. ha már csak egy kicsit is magasabbra merészkedünk a C-nél, akkor pl. már az is probléma, hogy én nem vagyok kimondottan nagy c++ guru, de ha majd valamikor new-t akarok használni, akkor azt hogyan a francba fogom megcsinálni, hogy mit tudom én, ne valami sztenderd memóriafoglaló rutin hívását fordítsa a fordító, hanem az enyémet... Meg lehet gondolom ezeket oldani, C-ben pedig ha nem zavar, hogy van a függvényekben inline asm, akkor nem is olyan vészes, de azért sok illesztési gond van és ezért csodálkoztam az adán (ha más nem is, hát abban is van new) szóval biztos voltak vele szupások
    Mutasd a teljes hozzászólást!
  • Pontosabban ugye az oké, a linker dolga pl. a printf-re való hivatkozásnál mondjuk ha kell belefordítani a kódba magát a függvényt, de ugye nyilván egy linux-os gcc környezet printf-je nem közvetlen a képernyőre akar majd írni és nem is bios-híváskkal, vagy ilyesmi, hanem ugye kellenek neki az OS belépési pontjai. Na aztán én pl. nem tudom honnan lehet azt tudni, hogy melyik ANSI C függvény hivatkozik oprendszer-szintű dolgokra és melyik nem (ugye, ha szelektíven akarod őket használni), illetve ugye elkezdheted ezeket magad felüldefiniálni és az így keletkezett dolgot include-olod, stb.


    Hát egyszerű: a C standard lib nagyrésze platformfüggő (ugye az az egyik feladata, hogy elfedje a platformok különbségeit), ezért nyilván nem tudod használni egy oprendszer kódjában. (Amit használni tudsz, azok legfeljebb a memcpy, strcmp meg hasonszőrű dolgok, tehát ami a külvilággal nem érintkezik.) De pont az a szép a C nyelvben, hogy nincs összegyógyítva a standard libjével, vagyis nagyon szép C programokat lehet írni standard lib nélkül is :)

    (pl. irq állítgatás, deszkriptorok bizgetése stb.), de ilyenkor meg kell és fogalmam sincs milyen magas-szintű nyelv ezt éppen hogyan támogatja.......

    Ezeket szerintem mindenki ASM betétekkel csinálja. Ilyen rétegigényeket, amik ráadásul platformonként különböznek, nem sok értelme lenne nyelvi szinten megvalósítani. Valóban igazad van, hogy ezek a betétek nem szabványosak, de tudtommal nem is divat a fordítók közti hordozhatóság oprendszerek forrásánál. (Pl. a Linux kernel csak GCC-vel fordul. Biztos vagyok benne, hogy a Windows kernel is csak Visual C++-szal fordul.)
    Elvileg egy fokkal szabványosabban is lehet: ha a legalacsonyabb szintű dolgokat külön assembly fáljlokban implementálod, akkor nincs szükség a beágyazott assemblyre, de még mindig függeni fog a kód az adott platformon szokásos hívási konvenciótól. Plusz vannak olyan esetek, amikor a plusz függvényhívás, amivel C kód ASM-ot hív (vagy fordítva), már túl sok overhead lenne.
    Mutasd a teljes hozzászólást!
  • Jó, igazad van, ez a linker, csak most én is kevertem a szóhasználatot... Pontosabban ugye az oké, a linker dolga pl. a printf-re való hivatkozásnál mondjuk ha kell belefordítani a kódba magát a függvényt, de ugye nyilván egy linux-os gcc környezet printf-je nem közvetlen a képernyőre akar majd írni és nem is bios-híváskkal, vagy ilyesmi, hanem ugye kellenek neki az OS belépési pontjai. Na aztán én pl. nem tudom honnan lehet azt tudni, hogy melyik ANSI C függvény hivatkozik oprendszer-szintű dolgokra és melyik nem (ugye, ha szelektíven akarod őket használni), illetve ugye elkezdheted ezeket magad felüldefiniálni és az így keletkezett dolgot include-olod, stb.
    Aztán ugye van maga a direkt probléma amit te is mondasz, hogy rá kell venni a linkert, hogy legyen szép belépési pont a megfelelő helyen, stb ez is egy dolog és még arról ne is beszéljünk, hogy vannak ugye lowlevel cuccok, amiket egy normális c-programban nem lehet megcsinálni (pl. irq állítgatás, deszkriptorok bizgetése stb.), de ilyenkor meg kell és fogalmam sincs milyen magas-szintű nyelv ezt éppen hogyan támogatja.......[szerk.: tudom, hogy támogatja, csak a módról pl. fogalmam sincs, meg hogy szabványos-e(szerintem nem) stb.]

    Szerintem lehetne folytatni a sort, bár ezekre ugye elég egyszer rájönni elvileg, csak én ezekhez lusta vagyok - ha nekem kéne csinálni, ezek a részek úgyis pure asm-ek lennének és csak ami fölé épül az lenne már valami rendes nyelvben megírva
    Mutasd a teljes hozzászólást!
  • Nem tudom pontosan hogyan, de egy ismerősöm csinált adában oprendszert elvileg (én nem láttam közvetlenül még futni). Itt most nem is ez az érdekes közvetlenül, de azért mindenképpen elgondolkodtató: ha abban meg lehet oldani, hogy közvetlenül, rendesen generálja a kódot, akkor tuti valami mai c-fordítóval is lehet "csak binárist" fordítani, bár fogalmam sincs hogyan kell és mit állítgatni ehhez.


    Elvileg ez nem a fordító, hanem a linker dolga lenne. A fordító legyártja a gépi kódot, meg megjelöli, hogy hol hivatkozik a kód külső szimbólumra, és mindezt egy object fájlba elrakja. A linker csinál egy vagy több object fájlból egy futtathatót. Ha a linker tud olyat, hogy mindent statikusan linkeljen, és a végeredményt csak simán kiírja mindenféle fejléc nélkül, akkor megkapod a "csak bináris" fájlodat.

    Egyébként pont így néznek ki a bootszektorok és a COM fájlok. Az egyetlen trükkös rész az, hogy hogyan tudod rávenni a fordítót arra, hogy a belépési pontnak szánt kódot rakja az object fájl legelejére, illetve a linkert arra, hogy egy adott object fájlt pakoljon legelőre.
    Mutasd a teljes hozzászólást!
  • A legutolsó mondatot tudnád egy kicsit pontosítani? Az adatterületek ne kerüljenek bele a programba? Vagy csak a debug-info-val van a gond (opcióval kikapcsolható)?
    Mutasd a teljes hozzászólást!
  • "Ilyen korai IBM PC-m egyébként nekem is volt - aztán hülye fejjel odaadtam a nagybátyámnak aki szétszedte"

    Nekünk enterprise128-unk volt, tök retró lenne rajta szórakozni, ha meglenne még, de nálunk ez kicsit körbejárt a családban: vettünk egy 486-os PC-t és odaadtunk unokabátyáméknak tanulni, aztán amikor nekik is lett PC így tovább és valamikor a sor végén elkallódott - jó, nem csak odaadások voltak, hanem pl. közben cserélés: szintetizátorok, hifik, tévék és egyéb eszközök jártak összevissza emberek között.... de jó lenne ha meglenne

    Amúgy ez a BAPC amit valaki lejjebb linkelt tök poén, lehet hogy fel is teszem a telefonomra dosbox alá "játszásnak".

    ui.: Ja még valami! Nem tudom pontosan hogyan, de egy ismerősöm csinált adában oprendszert elvileg (én nem láttam közvetlenül még futni). Itt most nem is ez az érdekes közvetlenül, de azért mindenképpen elgondolkodtató: ha abban meg lehet oldani, hogy közvetlenül, rendesen generálja a kódot, akkor tuti valami mai c-fordítóval is lehet "csak binárist" fordítani, bár fogalmam sincs hogyan kell és mit állítgatni ehhez.
    Mutasd a teljes hozzászólást!
  • aztán hülye fejjel odaadtam a nagybátyámnak aki szétszedte

    Ma már egy csavar sincs meg, pedig alighanem aranyat érne

    Hát igen, tényleg nem kellett volna odaadni... ezt a pcforum-on is pont a múltkor írtam meg.
    Nem baj : Előveszed a nagybáttyádat, befenyíted, aztán ha bizonyos időn belül nem tudja visszahozni, akkor egy picit Őt is "megszereled". Aztán kezded előlről...

    Na jó, azért talán ezt ne... csak egy kicsit
    Mutasd a teljes hozzászólást!
  • Dióhéjban én is pont ezt írtam - kivéve a videokártyásított basic verziókat, ezekkel nem találkoztam. Ilyen korai IBM PC-m egyébként nekem is volt - aztán hülye fejjel odaadtam a nagybátyámnak aki szétszedte .

    Az alaplapon 256K RAM volt, ezt egy külön kártyával lehetett bővíteni 512-re. Ha nem volt winchester (10MB-os dupla magas, MFM vezérlővel) és floppy sem (360 K-s, szintén dupla magas) akkor a basic interpreter indult. És tényleg volt magnó csatlakozó, sőt a gép ki/be tudta kapcsolni a magnót, ha jól emlékszem DOS parancs, sőt BIOS hívás is volt erre. Volt benne egy relé, ami jó hangosat csattant ilyenkor. És persze jó kis mikrokapcsolós IBM billentyűzet. És Hercules kártya. Ma már egy csavar sincs meg, pedig alighanem aranyat érne...
    Mutasd a teljes hozzászólást!
  • Elnézést a többiektől,

    Woh, nem tesz semmit
    Mi köszönjük az infót, legalábbis én...
    Érdekes infók abból a korszakból, amikor még a szüleim is épphogy egyetemre jártak
    Mutasd a teljes hozzászólást!
  • >Akkoriba két sorszámozós basic volt elterjedve.

    Attól függ, "mikoriba". :) 1981-ben jelent meg a legelső PC modell. Ebben ha bekapcsoltad, bejelentkezett egy 8Kilobajtos rombasic. A microsoft csinálta egyébként. Voltaképp átportolta a 16bites 8088-asra a 8bites sztenderd bézikjét. Az első PC-k nem tartalmaztak floppy-t sem gyárilag, merevlemezt pedig végképp nem. Kazettás magnetofonos illesztő volt az alaplapra integrálva. Innen indult az igencsak szerény ROM-Basic.
    Rendelésre lehetett kérni floppy-t is, amin 1982-től már a Microsoft DOS 1.0 verziója elérhető volt. A BIOS-t úgy írták meg, hogy előbb megpróbált a lemezegységről felbútolni a DOS és ha ez nem sikerült, vagy nem volt lemezegység, akkor indult csak el a ROM-BASIC. Az első PC/XT-k már floppyval és rendelésre merevlemezzel készültek, a ROMBASIC pedig emiatt az oprendszerbe nem illeszkedett bele. Ezért a Microsoft írt egy "BASICA.COM (Basic-Advanced) nevezetű programot, ami elindította és lemezműveletekkel, miegymással kissé felokosította a ROMBASIC-et. Így DOS alól indíthatóvá vált a BASIC interporeter és a system paranccsal ki is lehetett lépni basic-ből dos-ba Jellemző, hogy az IBM, mikor felszabadította a gyors elterjedés reményében az IBM PC licencét, akkor mindent kiadott, kivéve a belső BASIC jogát. Emiatt a PC klón gépek nem tartalmaztak belső BASIC-et, azonban az összes alaplapján sokáig ott volt a BASIC ROM foglalata. (Ha az ember otthon akarta felokosítani, 2db 2732-es eprom ment bele, mivel a 8bites epromok így adták ki a 16bites adatsín szélességet.)
    A GW-BASIC volt 1983..1984 környékén az első, klónokra is használható, teljes értékű BASIC, ami a ROMBASIC+BASICA párost képes volt kiváltani. Nevét Greg Whitten és Bill Gates vezetékneveinek kezdőbetűiről kapta.
    1986 környékén sok kopogós basic (sorszámozós) volt forgalomban ezután, mielőtt a TB és a QB IDE felületű, kompájlerezős változatok megjelentek, ezek az első betűjelekben tértek el, általában a video vezérlőt jelölték. HBasic, Hercules monitorra. CBASIC CGA és EGA monitorra, kiterjesztett grafikával, stb.. A VisualBASIC DOS első verziója csak a 1992 közepén jelent meg. Persze hazánkban kissé később szocializálódtunk bele ezekbe. A ROMBASIC-et pl. 1991-ben klónoztam persze csak kíváncsiságból első, videoton alaplapos klón XT-mbe. Még ruszki TTL IC-k is voltak benne és egyszem hatalmasat csattanó, egyoldalas, MOM-floppy. (Erre futotta.)
    Elnézést a többiektől, kicsit elkapott a nosztalgia. :)
    Mutasd a teljes hozzászólást!
  • Akkoriba két sorszámozós basic volt elterjedve.

    Az egyik a BIOS-ba épített basic interpreter. Ez csak az eredeti IBM gépeknek volt - viszont ezek ha nem volt rendszer, akkor nem a non system disc or disc error üzenetet adták, hanem elindították a basic interpretert, mint a jó öreg Commodore 64.

    A másik a gw-basic volt, ez ugyanez csak MS-DOS-ra (a PC-DOS az IBM-es verzió volt, az MS-DOS volt a kompatibilis gépeké, és ebbe került a gw). Volt ezen túl a MS-féle QuickBasic, és a Borlandos Turbo, bár ez utóbbihoz nem volt szerencsém. Ja, és volt a MS-nek Visual Basic-je DOS alá is.
    Mutasd a teljes hozzászólást!
  • Hűha, szerintem az nem Turbo Basic volt, hanem valami más, és nem tudom mi volt benne a "T", de 100 hogy nem Borland termék volt, iskolában 286-os Toshiba gépeken 320k-s floppyról induló MS-DOS 2.0 rendszerlemezeken volt. Olyan volt, mint a GW-Basic (ami talán az MS-DOS 3-as verziójához járt) vagy a BW-Basic (FreeDOS-hoz tartozik), tehát a Turbo Basic-el és a QBasic-el ellentétben sorszámozni kellett a sorokat, mint a Commodore 64-en. Ja meg persze nem volt hozzá compiler, csak interpreter. Egyébként az első otthoni PC-nken MS-DOS 6.22 + Win 3.11 volt, így már QBasic tartozott a DOS-hoz.
    Mutasd a teljes hozzászólást!
  • Oh, köszönöm mindenkinek a hozzászólását!

    Érdekesek, majd megnézem őket, de most így hirtelenjében ez az este nem a legmegfelelőbb hozzá.

    De azért köszönöm mindenkinek!

    Mutasd a teljes hozzászólást!
  • HB1:
    Jé, egy sorstárs! :) Turbo Basic, meg QBasic-et szintén használtam sokáig, még a 286-os korszakban is. A TB valamivel gyorsabb EXE-t fordított, de a TBASIC is betett egy 36K-s rutincsomagot fixen mindig, így ennél rövidebb EXE-t nemigen lehetett benne írni. A C-- eleinte tényleg nem volt egyszerű, kellett kis elszántság hozzá. Azért a C-t ezzel kezdtem megismerni. A fordítója persze tudott ott is optimalizálni méretre, vagy futásidőre, de ilyen ASM közeli és rövid kis cuccnál a program megírásán több dolog múlik, mint a kompájler beállításán. Pl. lehetett makróként vagy rutinként is meghívni programrészt. Makró esetén szépen a kódot bemásolta a fordító az adott helyre, így a CALL utasítás végrehajtása se használt plusz időt, viszont a kódméreted megnyúlt annyiszor, ahányszor a makródat felhasználtad. Rutintként hívva meg csak egyszer volt letárolva. De fő erőssége abban volt a C-- -nak, hogy kínosan optimalizálva volt arra, csak a használt függvényeket, rutinokat forgassa be, valamint változóknak használhatott az ember CPU regiszert és megszokott C-s változókat vegyesen is. Így a kritikus helyeken irtó gyors+tömör lett a progi, a nem finnyás részeknél meg lehetett slendriánkodni. Egyébként nem egészen felülről ansi C kompatibilis a nyelv, de nincsenek nagy különbségek. Most ránéztem kíváncsiságból a honlapjára, vannak tényleg más windowsos példák is.
    Nadamhu:
    Vagy ASC-text helyett inkább grafikus objektumokat, szimbóumokat megfelelteni nekik? Végülis a grafikus programozási módszereké a jövő. :)
    Mutasd a teljes hozzászólást!
  • C--

    Anno nekem a Basic (Commodore 64 féle, QBasic és TBasic) után a második programozási nyelv volt, amit kipróbáltam, mert 96-ban az Új Alaplap egyik számának a floppy mellékletén rajta volt (és hát net hiányában azzal próbálkoztam, ami a kezembe akadt). Én akkor túl sokra nem jutottam vele (9 éves voltam), csak 1-2 nagyon alap Hello Worldnél alig hosszabb programot írtam benne, meg később jó volt, hogy láttam már C szerű szintaxist.
    Mutasd a teljes hozzászólást!
  • Tömörségben messze a stack alapú nyelvek vezetnek (lásd APL és társai):

    APL (programming language) - Wikipedia, the free encyclopedia

    Igazából ki lehetne dolgozni az APL-nek (vagy valami más stack alapú nylevnek, pl. a Joy-nak) olyan változatát, ami nem emberi fogyasztásra alkalmas, vagyis a tokenekhez bináris stringeket rendelve, amely az abszolút tömörségre van kihegyezve. Egy időben gondolkodtam ezen. Így elképsztő tömörségek érhetőek el, de igazából ennek ilyen mértékben optimalizálva már semmilyen üzleti előnye nincsen. (Annak még csak-csak van üzleti előnye, hogy bizonyos kódok nem túlságosan pazarlóan nagyok, de az extrém méretoptimalizálásnak nincs ma már üzleti előnye.)

    domearminnak írom, hogy a sebességre való optiamizálással is az a helyzet, hogy ahol van üzleti jelentősége, ott olyan profik dolgoznak ezen, és olyan mértékben optiamlizálnak, amivel nagyon nehéz lesz felvenni a versenyt. (Ilyesmihez általában speciális matematikai és algoritmuselméleti ismeretek kellenek, gondoljunk pl. videotömörítésre, NoSQL adatbáziskezelők magjára meg ilyesmikre, vagy vegyük figyelembe, hogy a GNU egyszerű ingyenes nagysázm szorzó libje 5 féle magas matekot használó algoritmust használ a szorzásra, a számok méretétől függően választva ki az optimális algoritmust.) Szal' nem biztos, hogy ilyesmiben üzletileg versenyképeset tudsz alkotni, ha most kezdesz programozni.
    Mutasd a teljes hozzászólást!
  • Volt régen egy kis pirinyóc fordító, BAPC néven. (BASIC, ASM, PASCAL, C nyelven írhattad a kódot vegyesen). BAPC példa és letöltés
    Több ismerősöm esküdözött rá. Ami engem illet, egy C-- (nem elírás) nyelvet használtam. Szintén ingyenes. Félelmetesen tömör kódot lehetett írni benne, direkt mérethatékony, de sebességben is közel optimális programozásra fejlesztette egy Peter Cellik nevű gyerek.
    Jellemző rá, hogy kezdőként egy 320*200-as, tetszőleges PCX képes tapétát is használó, grafikus ablakozó rendszert pl. 12KB-ból sikerült összepakolnom. Tömbben megadott listából nyitott és csukott önálló, vagy egymásba ágyazott menűket. Vagy egy mezei kört 512 bájtos kóddal sikerült rajzolni pithagorasszal, szögfüggvénnyel pedig 1004 bájttal. Alapból COM-okat készített, de támogatta az EXE-ben a tiny modellt is. Nálam profibbak príma kis demókat írtak vele akkoriban, 2K-s limittel. Forgó tóruszok, lobogó tűz, (250byte) plazmaáramlás (800Byte) mindenféle pofás animációk, képernyővédők, stb. De aranyos, űrhajós-lövöldözős játék is volt, talán 18K-s mérettel. :)
    Írtak benne még oprendszert is, Minüett néven...
    Letöltető innen
    Ma is sokan fejlesztenek vele. Ha jól emlékszem, vannak ma már WINDOWS és LINUX, illetve többféle mikrovezérlő alá is különféle header-könyvtárai, illetve demói.
    Mutasd a teljes hozzászólást!
  • a méret-optimalizációs-mizéria nem csak bennem van meg... rengeteg ember, oldal, program van, ami még mindig erre éleződik ki.


    Fontos az optimalizálás, de mivel a szoftverfejlesztés a legtöbbször üzleti tevékenység, nem lehet kizárólag erre koncentrálni.

    Egyszerű példa: te fizetnél egy fejlesztőt egy hónapig, hogy optimalizáljon, vagy elviselnéd, hogy a terméked kb. 2 másodperccel hosszabban indul?

    Egyébként ha ennyire érdekel ez a téma, van terület, ahol hasznosíthatod, de az nem a DOS.
    Mutasd a teljes hozzászólást!
  • Egyszerűen ezt szoktam meg : kis méret, optimalizált gépi kód, és akkor nyugszom meg


    Na de mire optimalizált az a gépi kód? Mert ugye alaphangon lehet méretre optimalizált, sebességre optimalizált, vagy a kettő közti kompromisszum. És akkor még azt nem vettük bele, hogy egy 386-os CPU-ra optimalizált kód nagyon másképp fog kinézni, mint egy Pentiumra optimalizált, az pedig különbözni fog egy Core i3-ra optimalizálttól...

    Én ha választhatok, biztosan nem a méretre optimalizálok. Egy programot egyszer tölt le az ember, és egy mai vinyón elfér sok GB. (Mondjuk azt amúgy sem a program szokta nagyrészt elfoglalni, hanem az adatfájlok.) Futtatni viszont valószínűleg sokszor szeretné, és nehéz lesz neki megmagyarázni, hogy mondjuk egy 20%-os teljesítménycsökkenés feltétlenül szükséges volt, mert így 5MB-ot meg tudtunk spórolni neki a háttértáron...

    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


    Ezt honnan tudod? Milyen statisztikát, közvéleménykutatást, szavazást olvastál, ahol ez jött ki? Magamat illetve ismerőseimet megfigyelve ez nem szokott lényeges szempont lenni. A rövid reakcióidő és a kis memóriahasználat nálam pl. sokkal nagyobb súllyal játszik, mint a program mérete.

    (Két példa: az Adobe Readert lecseréltem Foxit Readerre, az Azureust pedig uTorrentre. Mind a két esetben kisebb volt az alternatíva, de nem ezért döntöttem mellette, hanem mert 10-15s helyett 1-2s alatt elindult.)

    Ezt hogy érted, a Turbo Pascal 3.5?


    Gondolom a .NET Framework 3.5-re gondolt...
    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__


    Ja, bocs, ez tényleg igaz, erre én is gondolhattam volna. Bocsi.
    Mutasd a teljes hozzászólást!
  • Hát, pedig én azt látom, hogy a méret-optimalizációs-mizéria nem csak bennem van meg... rengeteg ember, oldal, program van, ami még mindig erre éleződik ki.
    És még mindig érvényes az, hogy egy program sokkal jobban eladható úgy, ha akár 50-100 KB-al kevesebb, mint a konkurense - én legalábbis ezt látom.

    Bár konkurencia még nálam olyan formában nem létezik, legalábbis egyenlőre info-ban legyőzni és kioktatni engem nem egy nagy mesterség
    Mutasd a teljes hozzászólást!
  • OK. Akkor fogadj el egy tanácsot, amiről én azt gondolom, sokan ide írták volna már.
    Halaszd el az optimalizációs törekvéseidet még egy-két-három évvel.
    Tanulj elméletet és gyakorolj. Fontos a terminológia ismerete is, mert a helyes terminus technicus híján, félreértések adódhatnak, amik pedig mindenféle negatív hatásokat eredményezhetnek.
    Nem tudom, hol és mit tanulsz most. Amennyiben az nem felel meg neked, válassz egy másik környezetet és programnyelvet és otthon használd, gyakorold azt. Mint láthatod itt szívesen segítenek, akár ebben is. Fejlesztheted a képességeidet azzal is, hogy önállóan kikeresed a programnyelv választással kapcsolatos témákat itt a prog.hu oldalain, és önállóan értelmezed azok tartalmát. Azután kialakítasz egy saját véleményt, amit aztán ütköztetsz itt egy idevonatkozó topikban a többiekkel. Ez így már persze már több mint egy tanács. A többit vedd bónuszként!
    Mutasd a teljes hozzászólást!
  • Ezt hogy érted, a Turbo Pascal 3.5? Biztos???
    Én sohasem vettem észre, és egyébként is... furcsállanám.

    Vagy másról beszélsz?
    Mutasd a teljes hozzászólást!
  • Köszi a bare-metal-t... meg mindent.

    Azért úgy látszik mégis vagy valaki ;>
    Mutasd a teljes hozzászólást!
  • É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)


    OK, ezt én is tudom, hogy nem vagyok egy profi... Ezért szeretnék tanulni... mondjuk úgy, hogy elismerem a kommenthibáimat, és nagyon megköszönöm, ha kijavítotok, mert akkor legalább megtanulom, hogy ezt-vagy-azt nem lehet, vagy ez-vagy-azt nem jól gondolom - nem jól írom.

    Az infotanár nem tanít, szakkönyvekre nem telik, az internetes tudakozás fogalmába pedig a fórumozás is beletartozik ;)
    Mutasd a teljes hozzászólást!
  • (Szerintem önmaga, ha ennyire fényezi)


    A felhasználónevem nem mond semmit???
    Vagy a szóköztrim zavar meg benne?
    Mutasd a teljes hozzászólást!
abcd