Cyrix főzőlap howto

Címkék

Gondolom mindenki emlékszik még a Cyrix névre hallgató CPU-kra. Lebegőpontos műveletekben gyorsak nem nagyon voltak, de cserébe megoldották egy kisebb szoba fűtésének gondját.

Hozzászólások

Amilyen gepek nyugaton szemetek, azokat itt az iskolak orommel fogadjak el, hasznaljak. Ezen azt hiszem, valtoztatni kellene.

Nekem is van egy PR300+ -om. Mivel nem volt elég erős a hűtése, és sajnáltam a pénzt új ventire, inkább visszavettem és most 166MHz-n üzemel "light-ositott" win2kval.

A geptrem egyik kedvenc gépe, annak ellenére, hogy a leglasabb. Anno úgy árulták, hogy P2 300MHz :) holott csak 586-TSC

Én anno domini a Cyrix 486-osok miatt hagytam abba az assembly optimalizálást. WIntel ill. AMD procikon a byte-byte szorzás 17-24 ciklus volt (ha jól emlékszem), a Cx-en meg 2 (!kettő!). Na innentől ugye a szokásos letáblázás csak lassított a kódon, meg rontotta a cache-hatásfokot.

Mondjuk még jó is, hogy abbahagytam, mert most ahogy hetente jönnek ki az új videokártyák (+doksi nélkül), az optimalizálás teljesen kiment a divatból (éljenek a terahertzek meg a nitrogén-hűtés).

Nem azon forgattam a Gentoo-t, hanem egy Athlon XP 2500+ -on :) Csak a sajat elore forgatott binaris csomagokat szoktam telepiteni. Ami kb. annyi, hogy egy bzip2-ot kitomorit es bemasolja jo helyre.

Egyszer forditottam egy rdate-et vele (1 db c file a forrasa) valami 3-4 percig tartott :)

Hat, en 64 bites mov utasitasrol nem tudok, inkabb azt gondolom, hogy a memory i/o resze a CPU-nak intelligensebben volt megcsinalva, mint kortarsaie. Pl. mig Pentiumon nem volt ajanlott ket 32 bites memoriairast egymas melle tenni, mert megfogtak a procit, es egymas utan lettek vegrehajtva, addig a Cyrix osszeparositotta a ket muveletet, ha a ket cim egymas utan helyezkedett el a memoriaban, es egy db 64 bites muveletkent hajtotta vegre. Mivel ez masfele optimalizaciot igenyel mint a "default", ezert erre letezhetett GCC patch. De aztan lehet hogy nincs igazam, es volt erre dedikalt utasitas is. De valoszinutlennek tartom, mert a gugli nem tud rola. :)

Egyebkent Intelen is meg lehetett csinalni ugyanezt a trukkot, csak ott ehhez az FPU-t kellett hasznalni, mert azon van 64 bites adattipus.

A 6x86-ba rengeteg intelligenciat zsufoltak a keszitok, nehany megoldasa igencsak megelozte a korat, es csak 2-3 generacioval kesobb bukkant fel mas gyartok... mondjuk inkabb azt, hogy mas x86 gyartok :) CPU-iban. Sajnos az FPU-nal mar elfogyott a szusz, igy a hasonlo elore-menekules nem sikerult, mint ami az AMD-nek a K6-2-vel, meg a K7-el bejott.

En kedvelem... pontosabban kedveltem a Cyrix procikat, es ezt vallalom is. Pont akkor eltem a legaktivabb x86 asmkoder korszakom, mikor egy IBM-feliratos, Cyrix 6x86PR200+ hajtotta a vasam 200Mhz-re tulhuzva, OS/2-vel. Gyors volt es stabil. Es egy masik CPU sem vitte olyan sebesseggel az integerre "optimalizalt" kodomat, mint az a 6x86. Ami eloszor kb. egal speeddel vitte, az egy Celeron 433 volt, ami ugye tobb mint 2x akkora orajel.

Azon kivul a scenergy.dfmk.hu-t, ami a mail/webszerverem egy Cyrix 486DX4/100 viszi, 120-ra tulhuzva, lassan 3 eve. Rekord uptime valami 392 nap, ami utan kezzel rebootoltam, upgrade (SuSE -> Debian) miatt.

Szoval Cyrixet nem fikazni! :) Egyebkent tudom h. iszonyu mennyisegu fos proci volt Cyrix maggal a piacon, de azok legtobbje ST, Texas, vagy hasonlo utangyartott borzalom volt, nem pedig az IBM gyaraiban keszult verzio...

Btw, ha valakinek van elfekvoben PR300+-nal gyorsabb 6x86MX, az szoljon, erdekelne. Akarok retropecet osszetakolni, es kellene bele vmi Cyrix proci, de lehetoleg a bikabb fajtabol. :)

Ja es igen, mar mas is mondta hogy orult vagyok.

nekem van egy ismerősöm aki anno Cyrix fanatic volt. snq- te ismered? :D

Hat az otthoni Linuxos routerben egy Cyrix PR166 muzsikal :) Jo tudni, hogyha vegleg kidol a sorbol a gep akkor lehet meg hasznalni valamire a procit :)

Mellesleg Gentoo Linux van rajta es minden binaris csomagot bzip2-vel kell kitomoritenem es semmi problemam nem volt meg vele. Azon kivul, hogy tetu lassu :)

Errol eszembe jut egy talany, amit azota se sikerult megoldani :) Volt egy havernak (igaz, dyn?) egy Cyrix CPU-val szerelt csodagepe es Linux futkoraszott rajta. kerem szepen azzal SEMMI gond sose volt, kiveve egyetlen egyet: bunzip2 az nem ment rajta (segfault). Szal ha vmi tar.bz2-ben jott, akkor egy masik gepen bunzip2 aztan mehetett a gepere. Ebben az az erdekes, hogy mi a fene kulonleges lehet a bunzip2-ben ami nem jott elo sok-sok mas programnak soha csak pont annal? :) Ez azert is erdekes, mert tobb kulonbozo disztrib kulonbozo verzioju bzip2 csomagja jart ott, sot volt forditva mindenfele CPU-ra "kezzel is" optimalizalassal vagy anelkul, az eredmeny ugyanaz. Es CSAK a bunzip2-vel (bzip2-vel - azaz tomorites eseten - nem emlexem h oszinte legyek). Na most ezt magyarazza meg valaki, komolyan, arra gondoltunk hogy van egy BZIP2 nevu - mittomen - CALL-hoz hasonlo opkod ami a Cyrix-on rosszul van implementalva :)

http://www.heise.de/ct/machflott/projekte/55961

Ez már régi vicc. Amikor kijöttek az első kerámiatokos P5 MMX 200-asok, akkor csinálta meg ugyanezt meg valami ausztrál arc 6 prociból. :))

Nem beszolni akarok, de 5W-tal nehez fozni (hint: 7805: 5V/1A max. kimenet...)