Szerző: roberto

2001. augusztus 13. 18:18

Angol legenda: intejú a GCC kiadásfelelősével, Mark Mitchell-lel

Az elmúlt héten készült egy interjú Mark Mitchell-lel, a GCC (GNU C Compiler) kiadásfelelősével, a CodeSourcery nevű cég társalapítójával és műszaki vezérigazgatójával. Az eredeti angol változat a juraj.bednar.sk -n olvasható. Következzék néhány szabadon fordított részlet az interjúból:

GCCAz elmúlt héten készült egy interjú Mark Mitchell-lel, a GCC (GNU C Compiler) kiadásfelelősével, a CodeSourcery nevű cég társalapítójával és műszaki vezérigazgatójával. Az eredeti angol változat a juraj.bednar.sk-n olvasható. Következzék néhány szabadon fordított részlet az interjúból:

Juraj Bednár: Mi a GCC 3.0 legnagyobb újdonsága?

Mark Mitchell: Szerintem a legizgalmasabb a GCC 3.0 integrált Java runtime libje. Sokat fejlődött a x86 kódgenerátor is, ez is fontos újdonság, hiszen rengeteg az x86-os GCC-felhasználó. Teljesen újraírtuk a C++ alacsonyszintű implementációját is, ezáltal a GCC 3.0-val fordított C++ programok sokkal kevesebb memóriát igényelnek.

JB: Problémák voltak a GCC 2.96-tal. Miért állították össze a disztribútorok ezt a verziót?

MM: Fontosnak tartom, hogy mindenki tudja: a Szabad Szoftver Alapítvány (FSF) nem bocsátott ki 2.96 verziószámú GCC-t. A Red Hat és egyéb cégek viszont igen. Ez elég nagy baj volt, a 2.96 ugyanis a fejlesztői változatból készült. A legszomorúbb a dologban az, hogy a Red Hat szakemberei tudták, hogy rossz ötlet a 2.96 kibocsátása, de a vezetőséget már nem voltak képesek erről meggyőzni. Részben nekünk, a GCC karbantartóinak is köszönhető dolog, mert túl sok idő telt el az új kiadás elkészültéig. Én is arra törekszem, hogy lecsökkentsem a GCC kiadásai közti időt.

JB: Előfordulhat, hogy a GCC 2.96 felgyorsította a GCC 3.0 fejlesztését?

MM: Ez bonyolult kérdés. Egyrészről a GCC 2.96-ban talált hibák javításai bekerültek a 3.0-ba is, másrészt viszont a Red Hat GCC-s fejlesztői a saját 2.96-os verziójukkal foglalkoztak, és nem a készülő 3.0-val. A cégek persze aszerint döntenek, hogy mivel tudnak a vásárlóik kedvében járni, még akkor is, ha ezzel esetleg nem segítik az FSF munkáját.

JB: Hány fejlesztő dolgozik pillanatnyilag a GCC-n?

MM: Lehetetlen lenne megszámolni. Több száz, de van egy tíz-tizenkét fős csoport, amely a munka oroszlánrészéért felelős.

JB: Mik a terveik?

MM: A legfontosabb a jövőben is a generált kód teljesítménye. Egyébként szívesen látnék egy erőteljesebb fordítót, amely nem akad le akkor sem, ha hibás a bemenete.

JB: Gyakori probléma, hogy a hardvergyártók nem adnak ki bizonyos technikai részleteket. Mi a helyzet a processzorok dokumentációjával?

MM: Az utasításkészletet tekintve minden népszerűbb, munkaállomásokba szánt processzor jól dokumentált. Viszont gyakran nem áll rendelkezésre elegendő információ az időzítésről. Néhány beágyazott rendszereket gyártó cég pedig egyáltalán nem ad ki információt a chipjeiről. Ezzel ellentétben az AMD például szorosan együttműködik velünk, már egészen korai stádiumban is sok információval látnak el minket.

Mi a GCC legnagyobb technikai előnye a többi fordítóhoz képest?

MM: A platformok közötti hordozhatóság. Ha olyan fordítót szeretnénk, amely ugyanúgy viselkedik különféle platformokon, akkor a GCC egyértelműen a legjobb választás. A másik nagy előnye a beépített assembly támogatás, amely különösen a beágyazott rendszerek és a kernel programozása terén hasznos, és persze nem elhanyagolható az a tény sem, hogy a fordító hibái [a szabad forráskódnak köszönhetően] gyorsan megjavíthatóak.

Nagyon széles az a skála, amin az állásinterjú visszajelzések tartalmi minősége mozog: túl rövid, túl hosszú, semmitmondó, értelmetlen vagy semmi. A friss heti kraftie hírlevélben ezt jártuk körül. Ha tetszett a cikk, iratkozz fel, és minden héten elküldjük emailben a legfrissebbet!

a címlapról