Egyébként nem rossz dolog, hogy az Aztec először ASM forráskódot állít elő, mert így elég egyszerű még kézzel kicsit optimalizálni a kódot. (ilyenkor mindig elgondolkodok, hogy tényleg ez volt a csúcs a '80-as években? manapság el vagyunk kényeztetve a szénné optimalizált fordított kódokkal).

Ezt amugy talan Fejszen is kommenteltem: ez nem tudom miert meglepo, ez manapsag is pontosan igy van a UNIX-szeru op'rendszereken pl Linuxon is. Az mas kerdes, hogy "normal" esetben user szamara nem lathato, mert egy pipe-on at atadja az assembler-nek, igy az asm-al nem is talalkozol, de amugy ott van kozben az is, es egyetlen kapcsoloval ra is birhatod, hogy adja oda neked inkabb. Xep128-nal is hasznaltam pl, hogy lassam, mit produkal

Kösz az infót! Be is írtam ide.

Akkor az már nem is az eredeti könyv teljesen, hanem bővített "kiadás".

Akkor az már nem is az eredeti könyv teljesen, hanem bővített "kiadás".

Igen, az Aztec és a HiSoft fordítóról van benne némi plusz infó, a Unix-os dolgok viszont kimaradtak belőle (nem sok).

Amugy szoban forgo C forditok csak a K&R szintaxist tamogattak fuggevenyeknel? Marmint erre gondolok K&R kapcsan:

Code: C

1. int example (a, b)
2. char* a;
3. char* b;
4. { ... }

Mig manapsag ezt mar nem kifejezetten szokas hasznalni mar, hanem:

Code: C

1. int example ( char* a, char* b)
2. { ... }

Az Aztec C a K&R szintaxist támogatja (a régi 7-es UNIX (és a cal.c) is azzal van írva. Az újat nem is fogadja el. A HiSooft-ot nem néztem, most a HiTech-hel próbálkozok. Az egy kicsit többet tud.

Ez is erdekes amugy, modern C compilerek meg mindig elfogadjak a "register" kulcsszot, de figyelmen kivul hagyjak, ui az optimalizalo kepessegeik alapjan onalloan, a register szerepeltetese nelkul is regiszterekbe tesznek dolgokat, attol fuggoen, hogy a cel CPU mennyit enged meg, es melyik/melyek az/azok a valtozo(k), amit erdemes szerinte.

Hasonló az inline kulcsszó a CPP-ben. Azt ugye a makrók kiváltására hozták létre, makrókkal ugyanis elég veszélyes dolgokba is belefuthat az ember...

pl. vegyük ezt az egyszerű függvényt (remélem, nem rontom el ):
bool IsOdd(int n)
{
    return (n & 1);
}

namármost, ugye ha szép, könnyen karbantartható kódot akarunk, akkor csinálunk egy soros függvényt is akár. Csak hát ugye nagyobb a függvény overhead-je, mint maga a függvény.

Erre találták ki az inline módosítót, amit a függvény elé írva olyan kód jön létre fordításkor, mintha kvázi makró lenne.

Namármost, arra akartam kilyukadni, hogy az inline is olyan, mint a register, hogy opcionálisan veszi figyelembe a fordító, de pl. ha be van kapcsolva az optimalizálás, akkor inline kulcsszó nélkül is "inline-olja" az adott függvényt a fordító, ha úgy gondolja, hogy úgy jobb lenne...

Hasonló az inline kulcsszó a CPP-ben.

A CPP az C++ itt? C-ben is van, legalabbis C99 -ben mar igen.

De amugy igen, voltakepp hasonlo, vegulis a mai modern compiler-ek eleg okosak, hogy maguktol is kitalaljak, mikor mi kell, ez igaz kb az inline -ra es a register -re is. Sot, szerintem az esetek 99%-ban (csak tipp persze) rosszabbul is jar az ember, ha megprobal okosabb lenni a forditonal, foleg egy modern architekturan, ahol van mondjuk 32db regisztered, es pl register -nel nem biztos, hogy fejben tartja mar az ember, hogy mit erdmesebb valoban CPU regiszterben tarolni es mit nem

Ugyanakkor, a register kulcsszo hasznalata elvileg azt is maga utan vonja, hogy "nincs cime", tehat az ilyen muveletet akkor egyes C forditok meg sem engednek, annak ellenere, hogy amugy a register kulcsszo sok mindenre nincs hasznalva ... Pl:


Ha nem hasznaljuk viszont a register kulcsszot, attol lehet, hogy a fordito azt csinal belole, am sajat magatol lemond errol, ha pl a cimet akarja valami, mig fentebb pl nem.

Masik hasonlo erdekesseg, hogy miket csinalnak a mai compiler-ek, az pl konkretan az volt, hogy pont emu irasnal futottam abba bele, hogy mi az optimalisabb (itt epp kepet akar renderelni az ember, es a p mondjuk legyen egy pointer ami mutat a kirajzolando pixel-re, a lenti pelda persze nem a valodi eset pont, de most mindegy):


Raadasul a "p" adott esetben nalam pl egy globalis valtozo volt, mert kell kesobb is. Nos, legalabbis gcc-vel (pont az emlitett -S kapcsolo hasznalataval, hogy lassam milyen asm kodot allit elo), kiderult, hogy a ketto kb tok ugyanazt erredmenyezi. Raadasul igen okos is a fordito: bar a "p" pointer nem igazi "register" tema, mert hat a renderelo fuggveny utan meg kell tartani az erteket, es eleve mint globalis valtozo szerel, stb, a gcc legalabbis azt csinalta, hogy egyszer betoltotte egy regiszterbe es szepen ott hasznalgatta, aztan a fuggveny vegen egyszer irta vissza a memoriaba. Meg az elso esetben is, ahol azt varna pedig az ember, hogy a sok p++ miatt ezt minden lepes utan megcsinalja. Valojaban, ez akar problema is lehet, ha pl multi-thread programunk van, es masik thread is nezi az erteket (es arra szamitunk hogy allandoan no), vagy pl oprendszert fejlesztunk, es interrupt handler, stb, ekkor ugye ajanlatos meg a "volatile" kulcsszot hasznalni, jelezve a forditonak, hogy ne csinaljon ilyen optimalizaciokat, mert lehet, hogy 'varatlanul' kell 'mashol is' az erteke. Na, igazabol - mint mindig - nem tudom normalisan, szepen es eleg precizen kifejezni magam de remelem azert ertheto

Es akkor lehetne meg olyan erdekessegekrol is beszelni, mint pl a "restrict" kulcsszo szerepe (szinten C99).