Az Intel úgy hiszi, hogy a korábban kötött szerződés értelmében a Global Foundries nem leányvállalata az AMD-nek, így az nem rendelkezik a 2001-ben a két vállalat közt megköttetett licenccel.
A bejelentés itt olvasható.
A HWSW szerint "Mindezek oda vezethetnek, figyelmeztet a cég, hogy az AMD 60 nap múlva elveszti a licenceket és ahhoz fűződő jogait, ha nem tudnak megegyezésre jutni a felek, vagy a szerződésszegés állapota nem szűnik meg. Ez egyet jelentene processzorai forgalmazásának leállásával. Az AMD szerint az Intel vádjai alaptalanok, és saját szellemi tulajdonának megvonásával fenyeget."
A cikk itt.
- A hozzászóláshoz be kell jelentkezni
- 3035 megtekintés
Hozzászólások
- A hozzászóláshoz be kell jelentkezni
A 64 bites kieg. nelkul pedig soxart nem er :) csak jo a marketingje.
De majd a Wintel csinal egy x86_64v2 tipust. :)
- A hozzászóláshoz be kell jelentkezni
már csak szoftver kell hozzá :)
- A hozzászóláshoz be kell jelentkezni
Csak nehogy ez a hulyeseg tortenjen tenyleg :)
- A hozzászóláshoz be kell jelentkezni
a Ms volt az, aki megbuktatta az intel 64bites x86 kiterjesztését azzal, hogy csak egy platformot volt hajlandó támogatni. az pedig az AMD64 volt, mert az készült el előbb.
- A hozzászóláshoz be kell jelentkezni
az itanium-ról van szó? mert itanium verzió van az xp-ből, ws03-ból és ws08-ból is
- A hozzászóláshoz be kell jelentkezni
Nem. Az Itanium nem x86 alapú.
- A hozzászóláshoz be kell jelentkezni
És ráadásul előbb is volt, mint az x86-64
- A hozzászóláshoz be kell jelentkezni
akkor miről?
- A hozzászóláshoz be kell jelentkezni
Vicces, hogy 3 platformra van Windows. (x86, x86_64, IA64).
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
az IA64 az nem x86, 64bites x86 kiterjesztésre mást szánt az intel.
---
/* No comment */
Ketchup elementál megidézése a sajt síkra
- A hozzászóláshoz be kell jelentkezni
Szerinted miért írtam külön platformnak? Tisztában vagyok vele, hogy az IA64 az Itanium.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
+ppc64
+alpha
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
ppc64?
--
.
- A hozzászóláshoz be kell jelentkezni
Az NT kernel egyik tervezési célja volt az is, hogy könnyen portolható legyen az egyes architektúrák között, más kérdés, hogy mára az x86 és az x86_64 vált domináns platformmá.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
ha a mindenkori windowsokat vesszük akkor igen. egyébként az NT volt az utolsó, ami támogatta ezeket a platformokat, az pedig nem ma volt.
az itaniumot sem támogatja a vista, csak a windows server 2008, az aktuális kiadások közül.
- A hozzászóláshoz be kell jelentkezni
Vista és WinServer közös kódbázisra épül, nem lenne nehéz portolni a WinServer-ből kihagyott dolgokat.
Csak gondolom ezért nem készítettek belőle portot:
"This edition was discontinued in early 2005, after Hewlett Packard, the last distributor of Itanium-based workstations, stopped selling Itanium systems marketed as 'workstations'.[22] As of July 2005, Windows XP 64-Bit Edition is no longer supported, and no further security updates were made available." [Wiki]
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Nocsak... csak nem egy szöget hallok beverődni az x86 koporsójába?! Talán megkezdődhet, aminek már régen meg kellett volna kezdődnie.
---
Linux is bad juju.
- A hozzászóláshoz be kell jelentkezni
Az x86 él, élt és élni fog. Töménytelen bináris áll hozzá rendelkezésre. Hasonló a helyzete, mint a Windows-nak. Sőt, kettejük sorsa egészen össze van fonódva.
- A hozzászóláshoz be kell jelentkezni
Igen, tisztában vagyok vele. Pedig csak egyszer kéne lenyelni az a békát, hogy mostantól emulátorral futtatjuk az x86 kódot és az új binárisokat már nem erre készítjük. Jó jit fordítós emulátortól talán 1-2 generációnyit lépne vissza a teljesítmény, ami már bőven használható szintet jelent.
Igazából csak eljátszottam azzal a gondolattal, hogy az említett két cég közül valamelyik kényszerből elkezd egy a mostani x86-os processzorokhoz hasonló kivitelű (desktop alaplapba, akár LGA775 vagy AM3 foglalatba rakható), de nem x86 ISA-t megvalósító processzormagot fejleszteni és hasonló árfekvésben piacra dobni. Szerintem egyébként nem is lenne túl nagy effort, csak a dekóder front-endet kell kicserélni a processzorban, az összes többi (cache, végrehajtóegységek, reorder buffer, TLB stb.) maradhatna változatlan. Ráadásul egy jó ISA esetén az új design validálása is sokkal egyszerűbb, mert nem kell az x86 összes régi legacy üzemmódját és ezek közötti állapotváltást implementálni majd ellenőrizni, hogy jó-e.
---
Linux is bad juju.
- A hozzászóláshoz be kell jelentkezni
a kesobbi itaniumokkal ez lesz a celjuk elvileg 2010 kornyeken jonnek majd, ha minden igaz
___
info
- A hozzászóláshoz be kell jelentkezni
Igazából ami elhatározás kéne a részükről, hogy végre csináljanak egy rendes risc processzort, és felejtenék már el ezt a cisc-es hülyeséget.
Gcc-t felfejlesztenék, a piac terítése előtt egy jól megcsinált, jól optimalizált compilerrel a procijukhoz, ez ütne a piacon.
IMHO.
- A hozzászóláshoz be kell jelentkezni
...izé, csak érdeklődöm, hogy miért olyan egyértelmű, hogy csak a RISC processzor lehet jó?
...nézzük...
RISC (Reduced Instruction Set Computer)
- Redukált (sokkal kevesebb) utasításkészlettel rendelkezik
- Elemi utasítások használhatók, de azt nagyon gyorsan képes végrehajtani
- Ugyan az utasítás végrehajtása gyors, a redukált (elemi) utasításokból sokat kell végrehajtani az adott feladat elvégzéséhez
CISC (Complex Instruction Set Computer)
- Összetettebb (komplex) utasításkészlettel rendelkezik
- RISC-nél nagyságrendekkel több utasítással bír
- Utasítás végrehajtása viszonylag lassú, de kevesebbre is van belőlük szükség az adott feladat elvégzéséhez.
Ha a fenti dolognál maradunk, csinálhatnának rendes CISC vagy RISC processzort is... ugye a visszafelé kompatibilitás a legtöbb jelentkező probléma (korlát) okozója.
Persze sok egyéb különbség van közöttük...
A CISC-RISC dolog talán kicsit hitvita is, önmagában egyik vagy másik alkalmazása nem feltétlenül jelent előnyt.
No meg gondolkodhatunk mikrovezérlőkben is, közöttük is megfordul mindkettő, nem feltétlenül csak PC-architektúrából lehet kiindulni...
...szóval azért azt, hogy a CISC architektúra "hülyeség", egy kicsit bátor dolog kijelenteni...
Az, hogy milyen eszközt használ az ember attól is függhet, hogy milyen célra szeretné használni... persze PC esetén általános célú processzorról van szó...
Szerencsére Linux sokféle gépen elfut, így túl nagy gondot egyelőre ez nem okozhat... :)
Apple építkezett sokáig RISC processzorra (pl. PowerPC), de pl. a routeremben is az van.
- A hozzászóláshoz be kell jelentkezni
Épp itt írtad le. CISC-s utasítások lényegesen bonyolultabbak. Alapvetően azt vették figyelembe, hogy könnyen kódolható legyen. Csakhogy amióta nem ASM-ben írunk minden vackot, hanem C-ben, C++-ban, újabban Java-ban, .NET-ben, mindenféle script nyelveken, és egy fordítóprogram állítja elő a kész gépi kódot, azóta sok értelme nincs annak, hogy viszonylag könnyen olvasható.
Ezzel szemben lényegesen bonyolultabb felépítésű processzort igényel, amit egyrészt drágább, nehezebb fejleszteni, másrészt drágább is a bonyolultabb felépítés miatt és összességében sokszor lassabb megoldást eredményezett. Ezen röhögtem anno, hogy az AMD gyk. 3-4 évig nem emelt órajelet lényegében (legyen mondjuk 1800 Mhz környékén, kezdve a K7-s Athlonoktól a mindenféle K8-s procikig) mégis gyorsultak a processzorok. (AMD K6 óta RISC) Ezzel szemben az Intel ott szenvedett, hogy hova emelje a P4-eseinek órajelét, hogy tudja tartani a lépést az AMD-vel. Aztán persze rájött, hogy nem fog menni, dobták is az egész netburst-s szutykot és leporolták a P1-P2 közötti PentiumPro mellékvágányt, és lett belőle egy szintén RISC-re bontó Core mikroarchitektúránk. Lehet feltűnt, de teljesítményben, fogyasztásban proba alázza a régi P4-s vonalat.
Komplexebb dolgokkal mindig csak a baj van az informatikában: nehezen optimalizálható. (IA64-re is sok helyről azt hallottam, hogy szép meg jó meg minden, csak épp annyira bonyolult, hogy nehéz rá jó fordítót írni).
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Azért keveritek itt a dolgokat picit.
Egy mai x86 processzor (Pentium Pro-tól, K7-től kezdve) A Cisc utasításokat rögtön a feldolgozás elején felbontja elemi, egyszerű utasításokra. Sőt a poén az, hogy egy modern Risc processzor is ezt teszi. (PowerPC 604-től)
Innentől kezdve a processzorok felépítése nagyvonalakban megegyezik, a funkciók ugyanazok, csak más-más trükkökkel operálnak a gyártók, illetve egyre több a végrehajtóegység, meg a cache.
Tehát a lényegi különbség a Cisc és a Risc között az, hogy a Cisc-nek a kezdeti dekódoló lépése bonyolultabb. Emiatt pár lépéssel hosszabb a pipeline. (x86: 8 lépés, PowerPC: 3-4)
A NetBurst (Pentium 4) architektúra meg azért lett rossz, mert durván megnövelték a pipeline-t. Amd k7-k8, Core 1-2, PowerPC G4-5: 20-25 lépés. NetBurst: 39. Tették ezt azért, mert hosszabb pipeline --> egyszerűbb lépések --> nagyobb órajel. Terveik szerint a NetBurst 10 GHz-ig skálázódott volna. Ez a sebesség már ellensúlyozta volna a hosszú pipeline hátrányát, csak ezt a sebességet sosem érték el.
További adat, hogy az x86 processzor bonyolultabb dekódoló része a mag 5%-át foglalta el 3-4 éve. Ez mára még kevesebb. Tehát ez sem számottevő hátrány.
El lehet már felejteni ezt a régi Risc vs Cisc vitát, mert már teljesen értelmetlen. Apple váltott, és... nem történt semmi. Az új gépek gyorsabbak mint a régiek...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
- A hozzászóláshoz be kell jelentkezni
+1, foleg, hogy egy x86_64 (cisc) meg egy sparc,arm(risc) kozott kb. a fo kulonbseg, hogy x86-on a legtobb utasitas operandusakent adhatsz memoriacimet, a risc-eken meg csak az olvaso-iro utasitasnak adhatsz memoriacimet. kb ennyi.
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
+ egy halom regiszter pluszban. Ami x64-nel is befigyel, de kevesebb, mint altalaban a RISC jellegu architekturakon megfigyelheto.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
azert nem irtam, mert pl. az arm-nak (arm9-et ismerem) kb. annyi reigsztere van mint az x86_64-nek.
szerk: egyebkent alapvetoen igazad van (meg persze vannak mas kulonbsegek is, pl. risc-en altalaban 3 operandus van a muveleteknel, x86-on 2)
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
Az arm9-et kicsit tul haladta mar technika, azota 16 regiszter a meno. PPC32-n 32 van. Plusz a RISC javara irhato, h a spec szerint minden utasitasnak illik egy ciklus alatt vegrehajtodnia, tobbek kozott emiatt szerepel a G4 SIMD muveletekben fenyesebben, mint x86-os tarsai. Lenyeg, h azert van ott meg par kulonbseg a ket arch kozott.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Az arm9-et kicsit tul haladta mar technika, azota 16 regiszter a meno.
arm9-ben is 16 regiszter van (marmint amit lat az applikacio). mikepp az x86_64-ben. most megneztem, az arm cortex A8-ban is (ez igazan modern cucc es riscnek mondjak).
Plusz a RISC javara irhato, h a spec szerint minden utasitasnak illik egy ciklus alatt vegrehajtodnia, tobbek kozott emiatt szerepel a G4 SIMD muveletekben fenyesebben, mint x86-os tarsai.
ez x86-on is igy van mar egy ideje, sot egy orajel alatt tobb utasitast is vegrehajt (szuperskalar), simd-t is. ellenben pl. ultrasparc III-on (nem a legujabb, de ezt hasznaltam) pl. egy szorzas kb. 5 orajel, tehat nem egy (es kozben amugy megall az egesz pipeline, hehe).
Lenyeg, h azert van ott meg par kulonbseg a ket arch kozott.
van, csak nem lenyegesek ( [szerk]es azaz[/szerk] nem nagyobbak mint ami ket risc (vagy ket cisc) proci kozott is van).
szerk2: szoval oke, ha az egyik proci egy utasitassal megoldja az univerzum egyenletet (es mindezt mikrokodbol), a masik meg csak osszeadni es kivonni tud de azt hardverbol, akkor az elso cisc a masik meg risc nyilvan, de en csak azt mondtam (amivel te ha jol ertem vitaba szalltal), hogy a gyakorlatban altalaban (es konkretan x86_64 eseten) nincs ilyen eles kulonbseg. na mindegy a cisc vs. risc kerdesnek ugy latom eleg nagy irodalma van a neten, en csak egy velemenyt (a sajatomat) irtam le.
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
Az utobbiban egyetertunk.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Az melyik resze az okfejtesemnek? Hogy csak a velemenyemet irtam le?
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
szoval oke, ha az egyik proci egy utasitassal megoldja az univerzum egyenletet (es mindezt mikrokodbol), a masik meg csak osszeadni es kivonni tud de azt hardverbol, akkor az elso cisc a masik meg risc nyilvan, de en csak azt mondtam (amivel te ha jol ertem vitaba szalltal), hogy a gyakorlatban altalaban (es konkretan x86_64 eseten) nincs ilyen eles kulonbseg
Ebben. Viszont egy aprosag van. Ha mikrokodban letarolod a The Big Bang Theory-t, azzal ket negativ kovetkezmenyt is bevonsz a jatekba: novekszik a CPU komplexitasa (ezzel a kihozatal aranyosan csokken, a fogyasztas no, satobbi), valamint ha kozben rajonnek, h megsem volt Nagy Bumm, hanem mondjuk a Nagy Keresztespok szotte az univerzum szovetet, akkor a vasat lehet roptetni. Ezzel szemben ha csak osszeadni es kivonni tud, de azt mocskos gyorsan, akkor eleg csak a szoftvert modositani. Erre eleg jo bar sarkos pelda volt a DNETC, ahol romma alatza az AltiVec-re optimalizalt klienssel a PPC a kortarsait.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
talán nem véletlen, hogy ma minden konzol Power/PC alapú cpura épül. plusz a rengeteg beágyazptt célkütyü stb. volt erről már egy hosszabb diskurzus itt.
- A hozzászóláshoz be kell jelentkezni
De az, hogy az x86-nak kevés a regisztere, az nem általános CISC jellemző.
Pl. amikor utoljára assembly-ben programoztam, kb. 94-ig, a motorola 68000-es család CISC processzoraiban 16 regiszter volt használható.
G
- A hozzászóláshoz be kell jelentkezni
Az erősen kérdéses, hogy a regiszterszám manapság mennyire számít.
Egy PowerPC 970-nek 32 általános regisztere és 48 rename regisztere van (belső regiszter a nem valós függőségek kiküszöbölésére).
Egy P4-ben ugyanez a két szám 8 és 120.
Nyilván az AMD megtehette volna, hogy nem 16-ra növeli az x86-64-ben hanem többre, de mégse tette. Ezek nem hasraütésszerű döntések, tehát vélhetően nem nagyon számít...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
- A hozzászóláshoz be kell jelentkezni
Ha azt nezzuk, h az x86 8 "altalanos" regisztere kozul csak 4 "valoban" az, eleg sokat szamit az a +8 regiszter, valamint, h az altalanossag fogalmat kiljebb terjesztettek. Pont emiatt az alacsony regiszterszam miatt alakult ki az, h stack-en csomo mindent tarol, mig ez RISC eseten a regiszterekre tamaszkodik. Persze, a L1 cache-ek ota ez nem olyan egetrengeto dolog, de ha azt nezed, h ezt szinkronizalni kell a memoriaval, valamint a teljesitmenye meg mindig alacsonyabb a regiszterekhez kepest, okoz nemi teljesitmeny veszteseget. ARMv6-on (es ugy altalaban a RISC architekturakon) speciel az r0-r3 regiszterek szolgalnak parameteratadasra es csak akkor foglalkozik memoriaban torteno parameteratadassal ha ennel tobb argumentumra van szukseg, es egyeb regiszter alapu optimalizaciora is lehetoseget ad amit a compilerek erosen ki is hasznalnak. Ez alacsony regiszterszam mellett kenyszerit a memoria hasznalatra. Azert lassuk be ezzel eleg sok memoria/cache muveletet meg tud sporolni. Az h ez x86 eseten (bocsi, m68k kimaradt az eletembol) a stack lett szokas/mervado koszonheto az alacsony regiszterszamnak is az elcseszett architektura mellett.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
többek között ezért sem tartom valószínűnek, hogy az x86 a közeljövőben sikeres tud lenni mobiltelefonok processzoraként. nem lehet mindig univerzális megoldásként a cache és mhz növelését alkalmazni, sikerrel.
- A hozzászóláshoz be kell jelentkezni
Volt idő, amikor teljesen igaz volt, amit írsz... a risc jobb volt, gyorsabb, stb. Kb. 80-as évek végén, 90-es évek elején.
De mostanában a cisc-ek is gyorsan hajtják végre az utasításokat.
Viszont... mivel kevesebb utasítás van a cisc procinak ugyanahoz a feladathoz, elég kisebb cache. A cache hit pedig fontos dolog, mert lehet akármilyen gyors a proci, de ha memóriából kell behúznia az utasításokat, belassul keményen.
G
- A hozzászóláshoz be kell jelentkezni
Ezt szerintem bőven ellensúlyozza az, hogy RISC-en rövidebb a decode, és hamarabb elindulhat a branch prediction...
Egyébként sem hiszem, hogy a fő problémát az utasításcache okozná, ha így lenne, már rég megduplázták volna...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
- A hozzászóláshoz be kell jelentkezni
Ezt szerintem bőven ellensúlyozza az, hogy RISC-en rövidebb a decode, és hamarabb elindulhat a branch prediction...
Egyebkent az intel doksi 14 staget ir a core 2 pipeline hosszara, az ibm meg legalabb 16-ot a ppc 970FX-re (tudom ez regi, nem tudom hol van ujabb es bikabb ppower - pl power6 - procirol doksi).
Nem ellenoriztem (ugye nem tudom szetszedni a procit es megnezni), de erdekes adat.
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
Amikor az erről szóló hozzászólást írtam, utánanéztem az adatoknak, és kiderült számomra, hogy a pipeline hosszába a decode részt gyakran nem számolják bele. Így lesznek ezek 20 alatt.
És így lesz a PowerPC esetleg hosszabb.
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
- A hozzászóláshoz be kell jelentkezni
ezt mire alapozod, megerzes? meg lehetne merni persze mispredictelt ugrassal a pipeline hosszt.
amugy az is lehet, hogy a decode esetleg 1-2 orajellel tovabb tart a core 2-nek, de mas helyen meg hamarabb vegez (...mint egy 5 eves ppc mag).
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
Többnyire látszik az ábrákon, illetve kiderül a szövegből, hogy a decode részt nem számolják hozzá. Nomeg az is gyanús, ha az egyik leírás 16-os a másik 24-es pipeline-t ír ugyanarra a procira...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
- A hozzászóláshoz be kell jelentkezni
hat melyik doksi, melyik abra, mert en nem talalom? Te is a core mikroarchitekturarol beszelsz? mindenesetre meg akarom merni ha otthon leszek.
szerk: argh, ja, hogy a ppc-re irnak 16-ot az egyik helyen 24-et a masikon. mindegy a core 2-t megprobalom majd megmerni, es ide megirom, biztos mindenkit erdekel!
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
Szerintem esélyed nincs megmérni, de sok sikert...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
- A hozzászóláshoz be kell jelentkezni
Na mericskeltem.
Olyan 15-16 orajel jott ki, szoval akar lehet az is, hogy a dekodolas nincs benne az intel doksi altal irt 14 stage pipelineban.
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
- A hozzászóláshoz be kell jelentkezni
Én úgy tudom, hogy az AMD a Global Foundries-zal csak gyártatja a processzorait, a licenceket nem adja át neki. Innentől értelmetlen a vita.
- A hozzászóláshoz be kell jelentkezni
ha olvastad volna épp az a gond, hogy az AMD nem adhatja tovább a gyártási licenceit más félnek. És az AMD éppen azt teszi a gyártás kiszervezésével.
---
/* No comment */
Ketchup elementál megidézése a sajt síkra
- A hozzászóláshoz be kell jelentkezni
Ezt valószínűleg számításba vették, valami csak lesz.
- A hozzászóláshoz be kell jelentkezni
nem hinném, hogy az amd-nél olyan hülyék, hogy erre nem gondoltak...
- A hozzászóláshoz be kell jelentkezni
Elolvastam és szerintem nem adja tovább a licencet, ha továbbadná, akkor a Foundries is árulhatná a procikat. Csak a gyártási kapacitást veszi meg (gépek, emberek, egyéb erőforrások), kvázi az AMD gyártja.
- A hozzászóláshoz be kell jelentkezni
Ez csak a szokásos kardcsörtetés. Egymástól licenszelik a technológiákat, így egy összeveszésen mindketten csak vesztenének.
Az Intel csak megpróbál betenni az AMD-nek, mert nyilván nem tetszik neki, hogy hirtelen pénz állt a házhoz, plusz addig sem a trösztellenes eljárásról beszél a sajtó...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
- A hozzászóláshoz be kell jelentkezni