A GCC fejlesztők is fontolgatják az i386 dobását

Szerszám

A GCC levlistán Steven Bosscher felvetette, hogy most, hogy a Linuxból eltávolításra került az i386 támogatás, nem kellene-e ugyanezt elkövetni a GCC-nél is. Ha ezt meglépnék, akkor a legrégebbi ix86 variáns, amelyet támogatnak, az i486 lehetne. Az i386 eltávolítása lehetővé tenne némi kódtisztítást a fejlesztők számára.

A szál itt kezdődik.

( DirtY_iCE | 2012. 12. 14., p – 00:23 )

megindult az a bizonyos lavina...

I hate myself, because I'm not open-source.

( vomberg | 2012. 12. 14., p – 01:02 )

Valahol ott lenne ésszerű meghúzni a határt, hogy az adott processzoron és a hozzá tartozó memórián (mennyiségileg értve) le lehet-e fordítani pl. a kernelt.

Aki mondjuk 16 MB Ram-mal le tud fordítani egy 40 megás 386-oson nem hogy egy kernelt de bármit is - kezdve ott, hogy egy 2.36-os kernel egy GCC 4-gyel már fel sem megy rá -, az protestálhat.:-)

Valahol a Pentium-II körül van az értelmes határa a dolognak, az alatt (már a P-I-est sem) nem lenne szabad támogatni a friss kernelekkel, fordítókkal semmit.

"Valahol ott lenne ésszerű meghúzni a határt, hogy az adott processzoron és a hozzá tartozó memórián (mennyiségileg értve) le lehet-e fordítani pl. a kernelt."

Látom, "A Párt" után már megjelent "A Kernel" is. Mégis melyik kernelre gondolsz? Nem tán a Linux-kernelre? És mégis miért? Valószínűleg nem egyedül Linuxon használják a GCC-t, így miért pont az lenne a kiválasztott?

Hallottál már arról, hogy "beágyazott rendszer"? Ha mázlid van, pár 10-100 KB memóriád van. Oszt ennek ellenére használják, nem kevés helyen. Fenti kijelentésed után viszont ez (GCC használata beágyazott rendszerekhez) felejthető. (Mármint ha a fejlesztők is így gondolnák, és ezt meglépnék.)

Felrémlett az a kb 1993-94 körüli idő, amikor egy 386-oson futtatott SCO UNIX-ra GCC-vel fordítottuk az X-et (ami még a korai XFree-t jelentette, nem a mai Xorg-ot). Ha jól rémlik 4 MB memória volt a gépben, és az egyik fájl fordítása a teljes munkanapot elvitte - ugyanis swappelt a rendszer rendesen a fordítás közben. Valószínűleg hol a fordító volt a memóriában, hol a fordítandó. De lefordult.

(Először az a kényszerképzetem támadt, hogy azt fogod írni, hogy "ahol le lehet fordítani magát a fordítót". Az se lenne kisebb sületlenség, de mégis valami halvány logika lenne benne.)

Szerintem az idézőjel elég jelzés arra, hogy mire reagáltam. Semmit nem szóltam a 386-os támogatás eldobásáról, kizárólag az "olyan architektúrát támogassunk amin kernelt lehet fordítani" ellen berzenkedtem, és próbáltam ellenpéldát felhozni, hogy az *számomra* miért nem jó érv.

Ha tudsz valakit, aki beágyazott fejlesztést csinál 386-ra, kérlek küldd el a GCC fejlesztőknek, mert ők nem találnak ilyet. Valószínűleg azért, mert ez az egész halott. Ráadásul:

"And as usual: If you use an almost 30 years old architecture, why would you need the latest-and-greatest compiler technology? Seriously..."

Minden szava arany.

--
trey @ gépház

Az i486 beágyazott rendszereknél a mai napig használatos, egy rakás SOC csak idáig támogatja az x86-os utasításkészletet. Nemrég dolgoztam pl amd geode lx800 proccikkal és néztem nagyokat először hogy mi bajuk van az i686 kóddal. Ráadásul ezek elég népszerűek. Egyébként nem tartom jó gyakorlatnak hogy csak eddig implementálják az utasításkészletet de nem értek annyira hozzá, biztos megvan rá az okuk.

Mármint hogy javuljon a fordító? A kérdésfeltevésből az sugárzik, hogy szerinted semennyi - ezt mondjuk nem a hup közönségének kellene megírnod, hanem a GCC / CLang-LLVM / OpenWatcom / stb fejlesztőknek, akik folyamatosan próbálják javítani a "terméküket". "Fiúk nyugodtan hagyjátok abba, ez jobb már nem tud lenni!" :-)

( PaXTeam | 2012. 12. 14., p – 23:56 )

a fordito altal generalt kod minosege nem a megcelzott architektura eletkoranak a fuggvenye, hanem a forditoe. es igen, i386-ra is javult a generalt kod az elmult evtizedek alatt, mivel a gcc egyre okosabb optimalizacios trukkokre tett szert (inline strategia, regiszter allokator, LTO, stb). a tree-ssa belso reprezentacio bevezetese ota (gcc 4.0) meg igazabol a legfontosabb optimalizalasok architektura fuggetlenek.

Kicsit maskeppen fogalmaznek.

A gcc-nek egeszen biztosan nem azert kellene dobni a 386-os tamogatast, mert a Linux kernel ezt teszi. Nekik is ugyanazt a kerdest kellene feltenni maguknak, amit a kernelfejlesztok megtettek. Azaz mekkora hatranyt okoz a tamogatas megtartasa. Van-e valami, amit emiatt nem tudnak megcsinalni, van valami, ami emiatt tul komplikalt/nyugos lenne, stb. stb. Aztan, ha mindezen tuljutnak es az a matekolas eredmenye, akkor dobjak ki.

Tenyleg nem akarom minositen a 386 kerneltamogatas dobasanak a donteset, de inkabb a konkret projektnek kellene technikai dontest hozni, nem pedig a kolomp hangjat kovetni.

Az nem lehet, hogy attól mert a célhardver régi, még a fejlesztő gépe új, aktuális rendszerrel, amin mondjuk alapból az új gcc van? És nem neki kell, hanem azt kapja. Vagy ő inkább szedjen egy régi fordítót és tegye fel a "gyári" mellé? Vagy használjon fejlesztéshez régi rendszert amiben régi gcc van?

"Belépés díjtalan, kilépés bizonytalan."

Igen, teljesen elfogadható, hogy egy másik GCC verzióval fordítson valaki i386-ra mint a saját gépére. Ugyanezt teszem akkor is amikor PPC-re, MIPS-re, vagy ARM-re fejlesztek. Hol van ezzel a gond? Ennél sokkal nagyobb problémákat is meg kell oldani egy fejlesztőkörnyezet felépítésénél.

Nincs gond. Multiarch Debian + Mingw + Alpha OSF alá fordítóval tudom miről van szó, csak szerintem PPC, MIPS és ARM vs. Intel kicsit másabb, mint i386 vs. i486. Tényleg annyi plusz energiát igényel az i386 ág karbantartása mondjuk az i486 ághoz képest? Nem vagyok processzor architekturális guru, így kérdezem attól, aki jobban ért hozzá.

"Belépés díjtalan, kilépés bizonytalan."

( horvatha | 2012. 12. 14., p – 10:49 )

Aktív gcc használóként támogatnám, nemcsak az i386, hanem a 486, de akár a Pentium-I támogatás dobását is. Akinek ilyenje van, használja a régi gcc-ket.

Inkább az újabb procik rendes kihasználására kellene időt fordítani.

Szerintem...

-
A pár wattot fogyasztó Vortex86 beágyazott rendszerek is élnek, és 486-os instruction set-et
igényelnek. Egy Vortex86-os gép kb. annyit fogyaszt bekapcsolva, mint egy normál PC-s munkaállomás
kikapcsolva. És a sebességük már olyan ezeknek, hogy rengeteg feladatra alkalmasak.
De beágyazott 386-os gyártás is volt még kb. 4-5 évvel ezelőttig "M6117D SoC" néven,
így még csomó ilyen gép fut ma is speciális környezetben. Igaz, ezek max. DOS-t vagy
valamilyen régi fordítóval gyártott minimál Linuxot futtathatnak.
Szóval én a 486 támogatást azért megtartanám.

( turul16 v | 2012. 12. 16., v – 08:06 )

Es arrol nem irnak, hogy minden ma hasznalt micro vezero / dsp tamagotasat viszont bele rakajak ? :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.