Megjelent a Portable C Compiler 1.0-s verziója

Címkék

Anders Magnusson nemrég bejelentette a Portable C Compiler 1.0-s verzióját. A bejelentés szerint a fordítóprogramnak mostanra jól kell működnie amd64 és i386 platformokon BSD-k, a legtöbb Linux és Windows alatt. A bejelentés itt olvasható. További részletek a projekt weboldalán.

Hozzászólások

Tudtok olyan törekvésről, hogy ezzel a fordítóval fordítanak teljes BSD vagy Linux disztribúciót?

kérdés, hogy a választás lehetősége megér-e valamennyi programozói erőforrás-pazarlást, és ha igen, mennyit.
kérdés még, hogy azok az emberek, akik most saját érdeklődésük szerint c fordítót hekkelnek, beállnának-e másik csapatba vagy hagynák az egészet a pokolba, ha rájuk lenne erőszakolva egy döntés.

nem látom magától értetődőnek, hogyha összevonnának projekteket, automatikusan összevonódna az erőforrás is.

...vagy szuletik egy N.-ik fork, ami nem hasonlit mar egyikre sem, ellenben nagy lehetosegek vannak benne, es kurvajo lenne, de amint kiengedjuk a fejlesztoket a szobabol, mennek vissza a sajat forditojukhoz.

Ezutan par vilagmegvalto diak felkapja a munkat, es diplomamunka kereteben tolja majd tovabb a fork szekeret, majd kapnak nemi tamogatast is ezutan, hogy egy-ket evet meg elszuttyogjenek rajta, par ev mulva lesz nemi hype, hogy "NEZZETEK! MEG MOZOG!", es raugrik egy rakas ember, majd szegeny diakok latvan a kozeledo, habzo-szaju embertomeget, elfutnak messzire, es a project vegre meghal.

R.I.P.

--
|8]

Így van ez az autógyárakkal is. Mindenki más-más autót gyárt. Sőt, legtöbbje veszi a bátorságot, hogy egyszerre több típust gyártson, így növelve a káoszt. Ha összefognának, és egyesítenék az erejüket, akkor elég lenne egy autót gyártani, ami tökéletes lenne (és/vagy rohadt drága).

-----
"Én vagyok a hülye, hogy leállok magával vitatkozni."

Az analógia nem az árra, és nem a termékre "megjelenési" formájára vonatkozott. A lényeg az, hogy az Audinak és a Bentleynek valószínűleg több köze van egymáshoz, mint a Portabe C Compiler és a GCC fejlesztőinek. Mindkét közösség open source fordítóprogramot készít. <-> Mindkét cég autót gyárt (, és egy cégcsoporthoz tartoznak).

-----
"Én vagyok a hülye, hogy leállok magával vitatkozni."

Roppant szorakoztato, ahogy a tenyek ertelmezese nelkul egyesek megprobaljak mindenre rahuzni az autogyartast neha a leg toketlenebb modon.

Problema ezzel annyi, hogy a matek tanarokat se erdekli, hogy en milyen hasonlattal probalok megmagyarazni valamit, az ott leirt tenyeket(, szabalyokat, osszefuggeseket) kell(ene) ertelmeznem, nem bullshitet iderollkodni.

*Uncsik az autos "hasonlatok"*

----------------
Lvl86 Troll

A lényege az, hogy amíg lesznek különböző emberek addig lesznek különböző vélemények, ízlesek és igények is. Így van ez az autóktól a homoszexuálisokig mindennel és ez alól az informatika se kivétel.

Nyilván megvan a saját okod, hogy miért azt az oprendszert használod amit és milyen alkalmazásokkal. A fejlesztők is emberek, nekik is lehet eltérő nézőpontjuk és igényeik, nem csak azért fognak létrehozni egy új projectet, hogy csak legyen n+1 és ezzel téged jól megzavarjanak. :)

BSD-s körökben mindig is szerették az egyszerű, letisztult, könnyen karbantartható kódokat. Na most ebbe a képbe a - böhöm nagy - gcc nem annyira illik bele, ezert nyomatják a pcc-t is mellette.

3 hónapja végigforgattam a saját C kódjaimat mindenféle elérhető free compilerrel. A GCC egyelőre verhetetlen a kimeneti kód sebességét illetően. A fordítási idő nekem nem számít.

Mondhatni, én éltem a szabadsággal, de a nekem jobbat választom, ami még mindig a GCC. Szerintem sokan vannak így.

nem néhány elvakult gnu zealot kántálását kellett volna olvasni a hupon, hanem a főfejlesztő eredeti bejelentését, amiben leírta, hogy hobbiból bütyköli a pcc kódját és a célja az, hogy _újra_ lelehessen fordítani vele a netbsd forrásait (ugyanis 1994-ig a pcc volt az alapértelmezett fordító, a 4.4bsd kiadásával váltottak gcc-re [ami ugye megint megkérdőjelezhetné épeszű embernél azt a mendemondát, hogy a gnu licenc a gond, mert akkor nem váltottak volna eleve gcc-re anno]). ragge leírta azt is a bejelentésében, hogy már a userland fordul vele és 5-10 nagyságrenddel gyorsabban fordít, mint a gcc. a licencet csak zárójelben jegyezte meg egy smileyval, hogy a licenc geekeknel esetleg az is fontos lehet.

"és 5-10 nagyságrenddel gyorsabban fordít, mint a gcc."

Gondolom, inkább 5-10 szeres lesz, nem 5 nagyságrend, de a lényegi kérdésem:

Miért annyira fontos a fordítási idő, hogy mellette szívesen hallgatnak a kész kód sebességéről?

Saját number-crunching kódjaimnál kipróbáltam sokféle fordítót, és igaz, hogy a pcc sokkal gyorsabban végzett a fordítással, de a termék sebessége jelentősen alacsonyabb lett. Azt hinné az ember, hogy egy oprendszer-fejlesztőnek is a végtermék sebessége a fontosabb, nem az újrafordítás ideje. Vagy olyan sokszor kell újra fordítani a netbsd-t?

Fordítási idő fontossága: én szeretem, ha nem kell sokat várni, a netbook kifejezetten meghálálja ha nem gcc/clang-gal fordítom a saját *hobbi*vackaimat, ellenben hosszútávon sokkal kevesebb helyet foglal el egy pcc a rendszerben, mintha mondjuk ccache-t használnék. (Mai napig idegesít, hogy a hivatalos javac hányszor olyan lassú, mint a jikes volt anno - nyilván többek között a jvm berántásának köszönhetően. Nyilván ha valamit nem tud a jikes/pcc, akkor tök mindegy, hogy mennyivel gyorabban teszi. Viszont a jikessel ellentétben úgy tűnik a pcc fejlődik.)

Mindenki azzal tesztel amivel jólesik, itt egy tesztnek nem nagyon nevezhető apróság a nem nagyon távoli múltból, ez pl. a scimark2c-vel.

http://hup.hu/cikkek/20110223/pcc_1.0_beta#comment-1229426

Azoknak a projekteknek, amelyek napi szintű snapshotot csinálnak az épp aktuális állapotról (naponta lefordítják a forrásfát, vagy legalábbis egy részét), nagyon nem mindegy, hogy mennyi a fordítási idő. Főleg ha olyan oldskul architektúrákat is támogatnak, mint a vax és nem lehet mindent másik, gyors gépen cross-compile fordítani.

na jó, látom csak azért is elmagyarázod a feketéről, hogy fehér. a lényeg, hogy neked legyen igazad, de legalábbis nekem ne. most már sikerült annyira felidegesítened, hogy hajlandó voltam neked linket is túrni.

http://ivoras.sharanet.org/freebsd/freebsd8.html
http://forums.freebsd.org/showthread.php?t=7035
http://www.shiningsilence.com/dbsdlog/2009/08/12/4586.html
http://www.mail-archive.com/freebsd-ports@freebsd.org/msg27408.html

stb.

As the GCC compiler suite was relicensed under GPLv3 after the 4.2 release, and the GPLv3 is a big dissapointment for some users of BSD systems (mostly commercial users who have no-gplv3-beyond-company-doors policy), having an alternative, non-GPL3 compiler for the base system has become highly desireable. Currently, the overall consensus is that GCC 4.3 will not be imported into the base system (the same goes for other GPLv3 code).

Ebben a konkret esetben ez teljesen adekvat hozzaallas. 1001-edik Linux disztrot osszepakolni az LFS toolkittel eleg haszontalan, de a GCC mellett egy kiserleti mini-forditot (PCC) es egy bytecode-megkozelitessel mukodo LLVM-et fejleszteni kifejezetten ertelmes. A Microsofton belul is van par kulonbozo fordito, kernel, satobbi, a nagyreszuk megy a kukaba nehany ev/honap utan.

----------------------
while (!sleep) sheep++;

Attol fugg, mi kell neked.

llvm-gcc egy modositott gcc, ami llvm backendet hasznal gcc parserek mogott, ez volt Eloszor, mert csak.
llvm-dragonegg akkor jott be, amikor valami pluginesites tortent gcc-eknel, ezaltal lehetove valt a gcc frontend hasznalata anelkul, hogy ehhez gcc-t kellett volna hakolni. Hogy melyik jobb neked, az kb attol fugg, hogy milyen gcc verziot akarsz hasznalni, sacperkb ugyanazt csinaljak, csak mas-mas gcc verzioval.

Az llvm-clang meg a nativ parser, gcc nelkul.

Hogy melyiket szeresd?

Ha C/C++/ObjC-t akarsz forditani, nagy sebesseggel, es a kodod nem GCC-specifikus (vagy csak kis mertekben), akkor llvm-clang.

Ha a kodod nem fordul clanggal, akkor llvm-gcc.

Ha kiserletezni akarsz, mert pl olyan nyelv kell, amit llvm-gcc nem tamogat, akkor llvm-dragonegg. Ha ez eleri azt a szintet, hogy nem kell gcc-t patchelni hozza, akkor kb levalthatja llvm-gcc-t amennyire en latom.

Igazan egyszeru a valasztas szerintem.

S hogy miert van haromfele? Mert az LLVM fejlesztes egyes szakaszaiban epp masra volt szukseg, es mindharomnak vannak olyan elonyei es hatranyai, amelyek letjogosultsagot adnak a tobbinek.

De hasonlo megvan GCC kornyeken is, lasd a GOLD linkert. ;)

--
|8]

Mindez kb 2.5 perc alatt kideritheto, ha az ember ellatogat a http://llvm.org/ oldalra, es megnyit onnan 3 linket (clang, dragonegg es llvm-gcc). Az erdem az ovek, nem az enyem. En csak dumpoltam az informaciot, picit szajbaragosabb stilusban. (Mert en vettem a faradtsagot, es raszantam par percet a kerdeses oldal megnezesere ;)

--
|8]

A problema az, hogy eleve nem kene os-specifikus kodot irni. Almodozni en is tudok, a valosag attol meg mas lesz.

Nomeg van par GCC extension ami kifejezetten jo, es nagyivben leszarom, hogy ha ezeket hasznalom, akkor esetleg mas forditoval nem fordul a programom. Nem fogok azert gyatrabb (vagy agyonhakolt) kodot gyartani, hogy valami fisz-fasz forditocskaval is forduljon.

(Pelda: __attribute__((sentinel)) -t nagyon szeretem, __attribute__((unused)) -et szinten, ((artificial)), ((deprecated)), ((format ())), ((warn_unused_result)) csak az __attribute__(()) kozul, es van meg jopar hasznos feature gcc-ben, amirol nem vagyok hajlando lemondani, mert nagyban segitik a fejleszteseim)

--
|8]

Jah, kiveve ha epp az OS egy olyan szolgaltatasat kene hasznalni, ami mashol nincs (epoll/kqueue, de van ahol pl select sincs). Persze a legtobb VM-nyelv eseten vannak ezekhez fuggvenykonyvtarak, amik a dolog nagyjat elrejtik elolem, de ugyanez megvan C-re is, nem a nyelv sajatossaga ez.

Amig az OSek kulonboznek, lesz OS specifikus kod, virtualis gep vagy sem.

Van ahol a beallitasokat registryben tarolom, van ahol inkabb $HOME alatt kene - amire szinten vannak fuggvenykonyvtarak, de nem a nyelv sajatossaga ez.

Van ahol ilyen fajta hozzaferesi jogok vannak a filerendszeren, van ahol masmilyenek. Van ahol case sensitive a filerendszer, van ahol nem. Mindezek erosen tudjak befolyasolni a kodot, es bar joreszuket el lehet rejteni, a kod itt-ott OS specifikus marad.

Szep alom az, hogy a virtualis gepek elrejtenek mindent, de sajnos ez csak egy szep alom. Boldog lennek, ha valosag lenne, de sajnos ott meg nem tartunk.

--
|8]

> a virtuális gép nekem gyanús, hogy azért van, hogy ne kelljen os-specifikus kódot írni, hanem vm-specifikusat.

vs

> minimalizálni kell az os-specifikus kódot, ennyi.

No comment.

> a lényeg, hogy ne a nyomorult compiler-en múljon már a kód tisztasága.

Szerintem olvasd vissza, hogy mit irtam eredetileg, mert a peldaim amit felhoztam GCC mellett, nem OS specifikusak.

Ha az ember nem hasznalna a compilerek josagait, akkor meg mindig pre-ANSI C-t hasznalnank. Nem lenne az jo nekunk. A compiler azert van, hogy segitse a munkam, ha egy compiler inkabb akadalyoz benne, akkor azt nem fogom tamogatni. Igen, ettol compiler fuggo leszek, dehat ilyen az elet, tele van kompromisszumokkal.

--
|8]

Elárulok néhány dolgot akkor, mert látom nem vagy programozó. A VM nyelveknek is többféle implementációja létezik, még ha byte kód szinten ugyanazt is generálja többféle fordító, akkor is eltérő működésre számíthatsz eltérő platformokon. Aztán az igazi programok pont ugyan annyi platformfüggő cuccot használnak, mint egy C kód.
----
Hülye pelikán

btw a news section is megér egy misét:

"1.0 Release" -> "This is the beta..."

Szolgálati közlemény: az e hozzászólás feletti autós hasonlatokat homoszexuálisok írták.

De most miert, en ugy szeretem az autos hasonlatokat! Bar oszinten en forditva szoktam, az autoszerelonek probaltam szamitogepes hasonlottal leirni a problemat, mert autokhoz nem igazan ertek (elvezetgetni egyet-kettot meg csak-csak, de jobban nem is erdekel, nem is ertettem soha miert kell bamulni mindenfele autos magazint, meg csorgatni a nyalat XYZ autokra stb), legalabbis kevesebbet mint a masik temahoz.