mboost-dp1
openbsd
Der er et springende spørgsmål der trænger sig på: Hvorfor?
Nogen forklaringer? er det pga BSD licensen? (og at gcc er GPL-ish?)
Nogen forklaringer? er det pga BSD licensen? (og at gcc er GPL-ish?)
For OpenBSD er det bl.a. licensen, men det handler også om at OpenBSD udviklerne ikke er vildt tilfredse med den måde GCC udvikler sig på.
GCC ses som bloated, langsom og rodet, PCC skulle i følge OpenBSD være omkring 4 gange hurtigere. Et andet problem har været at GCC i de nyere version har droppet support for en del hardware arkitekturer, som OpenBSD stadig understøtter, som det er nu understøtter PCC kun x86, men fordi det er BSD tror jeg de regner med at de bedre selv kan vedligeholde det. Det kunne de naturligvis også med GCC, men OpenBSDs udgave af GCC indeholder en længere række patches, som GNU folkene ikke har ønsket at importere, og BSD udviklerne vil ikke forke et GNU program, fordi de ikke er enige i licensen og derfor ikke gider slæbe rundt på den. Det er i hvert fald sådan ca. min forståelse.
GCC ses som bloated, langsom og rodet, PCC skulle i følge OpenBSD være omkring 4 gange hurtigere. Et andet problem har været at GCC i de nyere version har droppet support for en del hardware arkitekturer, som OpenBSD stadig understøtter, som det er nu understøtter PCC kun x86, men fordi det er BSD tror jeg de regner med at de bedre selv kan vedligeholde det. Det kunne de naturligvis også med GCC, men OpenBSDs udgave af GCC indeholder en længere række patches, som GNU folkene ikke har ønsket at importere, og BSD udviklerne vil ikke forke et GNU program, fordi de ikke er enige i licensen og derfor ikke gider slæbe rundt på den. Det er i hvert fald sådan ca. min forståelse.
#4
Korrekt, GCC har en masse optimeringsmuligheder, problemet med mange af dem er bare at de er buggy af H til. Jeg personligt har arbejdet med projekter, hvor man var nød til at slå optimeringen fra på visse steder i koden, da GCC formåede at "optimere" det så meget, at projektet ikke kunne køre.
Det er et meget kendt problem at GCC er buggy, og hvis du kigger rundt i koden på mange open source projekter, vil du nok se nogle sure kommenterer hist og her, om workarounds for at få det til at virke når det er compilet med GCC (ikke mindst forskellige versioner).
Derved ikke sagt, at en ny compiler ikke kan have lignende problemer, men håbet er nok fra Open/NetBSDs side, at de kan have lidt mere indflydelse over denne compiler, og koden er en smule mere overskuelig end GCC (den har trods alt mange år bag sig), så sådanne problemer er nemmere at identificere og rette.
Korrekt, GCC har en masse optimeringsmuligheder, problemet med mange af dem er bare at de er buggy af H til. Jeg personligt har arbejdet med projekter, hvor man var nød til at slå optimeringen fra på visse steder i koden, da GCC formåede at "optimere" det så meget, at projektet ikke kunne køre.
Det er et meget kendt problem at GCC er buggy, og hvis du kigger rundt i koden på mange open source projekter, vil du nok se nogle sure kommenterer hist og her, om workarounds for at få det til at virke når det er compilet med GCC (ikke mindst forskellige versioner).
Derved ikke sagt, at en ny compiler ikke kan have lignende problemer, men håbet er nok fra Open/NetBSDs side, at de kan have lidt mere indflydelse over denne compiler, og koden er en smule mere overskuelig end GCC (den har trods alt mange år bag sig), så sådanne problemer er nemmere at identificere og rette.
#7,
Generelt har VC nu givet mig flere problemer med fejlkompileringer end GCC har, men det er selvfølgelig bare en personlig anekdote.
Bl.a. havde jeg et busy-loop (ja, grimt, det ved jeg) som VC syntes den kunne optimere til at være en uendelig løkke...
Noget i retning af:
Det var en sjov fejl. Den næste udgave at VC fiksede det dog, svjh.
#8,
Så vidt jeg ved er et af målene med (flere af) BSDerne lige netop alsidighed og portabilitet, right?
Generelt har VC nu givet mig flere problemer med fejlkompileringer end GCC har, men det er selvfølgelig bare en personlig anekdote.
Bl.a. havde jeg et busy-loop (ja, grimt, det ved jeg) som VC syntes den kunne optimere til at være en uendelig løkke...
Noget i retning af:
bool done;
do {
is_opengl_done(&done);
} while (!done);
Det var en sjov fejl. Den næste udgave at VC fiksede det dog, svjh.
#8,
Så vidt jeg ved er et af målene med (flere af) BSDerne lige netop alsidighed og portabilitet, right?
#9 GNU Compiler Collection er blandt andet problematisk fordi at portabilitet er et af de primære designparametre, ikke bare i forhold til software- og hardware-platform men også i forhold til programmeringssprog - derfor er den også modulariseret.
Dette er en ren C/C++ compiler, der får hjem på et begrænset antal softwareplatforme, nemlig BSD-familien. Men ja NETBSD kan blive et mareridt i dette henseende.
Dette er en ren C/C++ compiler, der får hjem på et begrænset antal softwareplatforme, nemlig BSD-familien. Men ja NETBSD kan blive et mareridt i dette henseende.
Skal vi lige lave et lille realitets check ?
Det grundliggende compiler design er fra 1973.
Der er ingen binutils - de vil forsøge at bygge på nogle binutils fra PDP-10 (og så snakker vi altså igen rigtigt gamle dage).
Det er kun C. Ingen C++.
Ingen Ada, ingen Java, ingen Pascal, ingen Fortran.
Der arbejdes dog på Fortran 77 (som jo så også er 2 versioner bagefter).
Og så vidt jeg kan læse mig til så er det:
- næsten en non optimizing compiler
- uden runtime library
- x86 only
Jeg har lidt svært ved at se, hvad der er her som enhver datalogi studerende der har taget compiler teknik ikke kunne lave i et speciale.
Der må være smidt hundredevis måske tusindevis af mandår i GCC siden udviklingen af pcc stoppede.
Jeg har lidt svært ved at se hvorfor man tror, at man sådan uden videre kan indhente det.
Et par links:
http://www.ludd.ltu.se/~ragge/pcc/
http://undeadly.org/cgi?action=article&sid=200...
http://developers.slashdot.org/article.pl?sid=07/0...
PS: Ifølge wikipedia så er kilden til at pcc kan erstatte GCC netop den "superpålidelige" kilde Slashdot.
Det grundliggende compiler design er fra 1973.
Der er ingen binutils - de vil forsøge at bygge på nogle binutils fra PDP-10 (og så snakker vi altså igen rigtigt gamle dage).
Det er kun C. Ingen C++.
Ingen Ada, ingen Java, ingen Pascal, ingen Fortran.
Der arbejdes dog på Fortran 77 (som jo så også er 2 versioner bagefter).
Og så vidt jeg kan læse mig til så er det:
- næsten en non optimizing compiler
- uden runtime library
- x86 only
Jeg har lidt svært ved at se, hvad der er her som enhver datalogi studerende der har taget compiler teknik ikke kunne lave i et speciale.
Der må være smidt hundredevis måske tusindevis af mandår i GCC siden udviklingen af pcc stoppede.
Jeg har lidt svært ved at se hvorfor man tror, at man sådan uden videre kan indhente det.
Et par links:
http://www.ludd.ltu.se/~ragge/pcc/
http://undeadly.org/cgi?action=article&sid=200...
http://developers.slashdot.org/article.pl?sid=07/0...
PS: Ifølge wikipedia så er kilden til at pcc kan erstatte GCC netop den "superpålidelige" kilde Slashdot.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund