Karib, te tudtál erről a cikkről?

2. oldal:.... de nemcsak buta, pénzéhes közgazdászokból áll. Lenne a helyes mondat.

hm.
a cikk íróját, azaz Prcyt semmiképp sem szeretném kritizálni, mert regeteg jó munkát olvastam már tőle ezen az oldalon, de most úgy érzem ki is kell egészítenem a cikket, és ki is kell 1 kicsit javítanom:
kijavítás:
a HAMMER processzorok nem lesznek tisztán 64bites processzorok, ugyan lesznek benne 64bites regiszterrek, de a végrehajtóegység csak 32bites lesz. az amd-féle x86-64 doksiban ez benne is van: 1 64bites utasítás végrehajtásához 2 órajel kell a 32bites végrehajtóegységen. a processzor támogatja, hogy az egés program 32bites operandusokat használjon, és csak a memóriacímzés legyen 64bites(fizikailag csak 48, de sztem annyi ramot még soha nem tettek 1 procihoz...) a doksiben erős ajánlásként benne van, hogy továbbra is maradjunk a 32bites operandusoknál. ezesetben nem lesz teljesítményveszteség. no persze nem is lesznek 64bites utasítások. de mihez van szükség 32bites utasításra? hát elég kevés dologhoz. 1 adatbázis vagy webservernek semmiképp sincs, annak bőven alég a 32bit. 1 renderer gépnek szüksége lehet rá, ha 64bites színmélységbe renderelnek. de mivel az emberi szem csak kb. 26bitnyi színt tud megkülönböztetni, erre nincs szükség. e renderer sokkal többet profitál a SIMD utasításokból.
1 CAD gépnek kell a 64bit? igen, itt ki lehetne használni a 64bitet, és valószínűleg a nagyobb munkáknál még a 2 órajeles veszteséggel együtt is sokat profitálhatnak a 64 bitből(tekintve, hogy ha nagy térben dolgoztunk, akkor eddig is megvolt a 64bites(vagy mégtöbb pontosság, csak a szoftver rakta ösze 32bites művelekből)
így el lehetne még morfondírozgatni, minek kell,, és minek nem kell a 64bites művelet, de a programok döntő többsége nem profitál sokat(vagy éppen semmit) a 64bites utasításokból. tehát ha maradunk a 32bites utasításoknál, akkor nem vesztünk sokat, de a 64bites memóriacímzéssel megszabadulunk a 32bites memóriacímzés korlátaitól, ami meggátolta a mai PC procik komoly felhasználását(na jó, sokminden van még, a 32bites memóricímzés csak az egyik)
(off: már a P3 és a P4 is tud 36bites memóriacímekkel működni, azaz 32GByte memóriát megcímezni, de az adatbusza miatt(ami 64bites) így 2*32bitet használ fel 1 memóriacím továbbításához(eléggé amatőr megoldás) ezzel meglehetősen jelentékeny mértékben lecsökkentve az amúgyis kcsi memóriasávszélességet, ezért soha senki nem is használta, több volt a hátránya, mint az előnye.)

helyreigazítás:
a processzorok elemzésekor kihagytál 1 nagyon nagyon fontos dolgot: makrokód
ez a makrokód egy afféle RTC(Run-Time Compiler azaz futtatási-idejű fordító) ami teljes egészében a processzoron belül található. a lényege az, hogy a bonyolultabb utasítáokat több, egyszerű utasításra bontja szét, ezzel meg lehet spórolni 1 csomó szilíciumot, mivel a ritkán haszunált bonyolult utasításokat beleteszik a makrokódba. ez 1 kicsit lelassítja a működést, de ez elhanyagolható veszteség, mivel az utasítást ritkán használjuk, és a megspórolt szilícium(és komplett végrehajtóegység) nem lassítja amprocit, és magasabb órajelet érhetünk el(nmem is beszélve a tervezés megkönnyítéséről). ez a markrokód nagyon régi találmány, ha jól emléxem, az intel procik a 80186 óta használják, de ebben nem vagyok biztos... tehát a P3/P4/athlon /K6/akármio processzorok egyserűen nem azokat az utasításokat hajtják végre,a mik a gépi kódban szerepelnek. az x86 utasításoknak scak nagyon kicsi hányadát tudja a processzor ''alapból'' végrehajtani, az utasítások több mint 90%-át a makrokód által generált új utasítások formájában hajtja végre a processzor.(a makrokód nem csak a CISC processzorokra jellemző, pl. az US3, ami vitán felül állóan RISC processzor, még az US3 utasításainak is több, mint 60%át átalakítja a makrokód) és akkor a lényeg: a P3ban, P4ben, P3ben, athlonban, és a hammerben csak 32bites végrehajtóegységek vanna, ha 16 vagy esetleg 8bites kódot hajtunk végre, akkor azokat mindenképpen a makrokódintézi, azaz a 16/8bites adatokat beleteszi 1 32bites regiszterbe, és a számítás elvégzése után az utolsó 8/16 bitet másolja a memóriába/következő regiszterbe csak. 8/16bites kód esetén a makrokód tehát az utasítások 100%át megpiszkálja, de nincsen csak 1 processzormagunk.
a makrokódnak köszönhetően lehetővé válik a processzormagot viszonylag függetléeníteni az ISAtól. agy pl. a P6os processzoroktól kezdve minden(de már a P5ös is eléggé) RISC maggal rendelkezik, és a makrokódnak köszönhetően tudja a teljes x86 utasításkészletet végrehajtani.
tehát a processzor nem cipeli magával a régi magokat is, csak cvsak ''szoftveres'' megoldás, hogy a régi kódot még mindíg végre tudja hajtani.
most már nagyon álmos vagyok, majd belejezem.
ha még valami nem világos, akkor azt majd holnap elmagyarázom még.

értelmező késziszótár :: rekurzió --> lásd : rekurzió

Miracle!

Egyrészt, köszi a kiegészítést, picit beleírtam a cikkbe.
Másrészt viszont szeretném megvédeni a firkámat :)... természetesen az x86 ASM jóval komplikáltabb, mint egy ilyen cikk, és a cikk ilyen értelemben semmitmondó, de már így is ''technikaibb'', mint cikkeink nagyrésze. Tehát, pár őrült ASM rajongón kívül úgy sem foglalkoztatna senkit, így nem is mentem bele az operandusok, regiszterek, memóriacímzés, RISC-86, és egyéb nyalánkságokba (egy részükbe nem is tudnék komoly utánajárás nélkül).

Tehát: a cikk szándékosan egyszerű, és csak a regiszterek oldaláról ''vizsgálja'' a kérdést. Tény, hogy az XT mag nem egy az egyben van a prociban, de akár szoftver konverzióval, akár hardveresen, de valahogyan ''cipelnie'' kell, és bármelyik megoldás fölösleges tranzisztor és cikluspazarlás...

dicranum scoparium + genista pilosa = :)

ejj parci, most olvasom végig harmadszorra és megelehősen felbosszantott ez a rossul sikerült TIT stílus. Aki ebből érti, hogy miről van szó az leginkább kineveti, aki meg nem, az ezentúl ilyen baromságokkal fogja éltetni magát a pletykarovatokban. Vigyázzunk már arra, hogy mit írunk, mert ezzel csak a sötétséget növeljük tovább a fejekben és nem a célt érjuk el.

A téma a leírtaknál enyhén szólva is bonyolultabb és sokkal árnyaltabb megfogalmazásokat kíván.

Ge.

BadGe, pl.?

prohardver vendég

Emberek, szerettem volna ''1 egységgel'' többet írni arról, hogy az Itanium 64 bitjéhez képest a Hammer nem ''igazi'' 64 bites processzor. És erre felhoztam a regiszterek példáját. Pont.

Mi ezzel a gond? Csak akkor lenne jó a cikk, ha 18 oldalon keresztül lenyomnám a Hammer whitepapert, és utána még az NDA alatt álló Hammer BIOS Writer's Guide-ot? Most komolyan, hány hardcore ASM-es van az olvasóink között? Tőlük ''elnézést kérek''.

dicranum scoparium + genista pilosa = :)

Olyasmiben gondolkodjatok, hogy az emberek javarésze (és itt nem az átlagemberre, hanem a minket olvasó, hardver iránt fogékony emberekre gondolok) még sosem hallotta azt a szót, hogy regiszter (ilyen értelemben), és időbe kerül, mire megemészti még ezt a laikus hozzáállású cikket is.

dicranum scoparium + genista pilosa = :)

Jó volt a cikk Parci, de tényleg akik értenek hozzá azoknak kevés információt tartalmazott, és szerintem egy kicsit egyoldalú is volt. Akik meg nem értenek hozzá azok meg ezentúl a fórumokon nagypofával nyomják majd a sódert, hogy szar a HAmmer mert még XT magot is tartalmaz.

Csak így tovább :-)))

Mindenkinek egy ilyen középső ujjat mutatnék .I..

Azért a cikk első része rendesen elpáholja az Intelt... a Hammer pont, hogy nem szar, sőt, a Yamhill mutatja, hogy életképes alternatíva. ''Technikailag'' nem egy elegáns megoldás... (bár az EPIC-et is lehet kritizálni, de ez már egy másik történet, és a hátrányai ellenére az EPIC/Itanium legalább egy ''nulláról megcsinált'', igazi 64 bites cucc).

dicranum scoparium + genista pilosa = :)

Bazz, pont ezt a rohadt 8086-ost tanulom, holnap írunk belőle. :))

7447 óta folyamatosan...

Miért van az, hogy mindenkinek olyan nagy a pofája? Mintha mindenki kutatómérnök lenne az Intelnél vagy valami!

Igenis jó a cikk! Engem csak alapszinten érdekel a Hammer, meg az egész 64 bites cécó, így nem foglalkozok annyit vele, és ez a cikk pont elegendő infót tartalmazott, hogy megértsem a témát, és egy újabb dologgal okosabb legyek.

Nekem ennyi kellett, megkaptam. Aki meg ennél jóval többet tud, az jelentkezzen valamelyik nagyobb cégnél, úgyis a magyar tudósokat mindenhol szívesen látják! :)

COOLNESS! - somebody ssssstop me!

Akkor ne nagyon mélyedj el ebben a cikkben mert
a 8086-os része téves. Pl. nem 8 hanem 16 bites a 8086-os. Az AX éppen ezért már ott is használható egyben.

Zoltán

prohardver vendég

igen, a 8086 16bites cpu, de az ibm, aki értelmes gépet épített köré 8bites adatsínt használt(meg mindenki más is) és ezért maradt minden 8bites, nem pedig 16 bites.

értelmező késziszótár :: rekurzió --> lásd : rekurzió

Igen az XT/ISA adatbusz kifelé valóban 8 bites, de pl. a címbusz már az XT-ben is 20 bites volt. Az pedig, hogy kifele csak 8 az adat csak gondolom költségcsökkentő tényező volt. A lényeg, hogy 16 bites regiszterei vannak. AX, BX, ... SI, DI mind-mind 16 bites.

Zoltán

prohardver vendég

ok, igazad van, a régebbi rendszerekben nem vagyok igazán járatos. meg az újabbakban is csak hobbiszinten.
de azt tudom, hogy azért volt 8 bites, mert az IBM csinált 8bites adatbuszú ''chipsetet'' a 8008ashoz, majd kijött a 8086os, és azt nem építették be, mert az intel utána kiadta a 8088ast, ami belekerült a PCbe, mertvolt hozzá chipset...

értelmező késziszótár :: rekurzió --> lásd : rekurzió

Jó a cikk, gratu Parci. Én is laikus vagyok, regisztert még fel tudom fogni, stb.
DE! Miért is jó nekünk a 64 bites proci?
Mert én Marha jól elvagyok a mostani 32 bites vackommal...:))
Tehát jó-e az nekünk, ha ilyen vagy olyan formában lesz 64 bites rendszerünk?

Csak okosságot várok válaszként! :D

#tarcsad

Azt hiszem két dologról beszélünk. A 8086/8088 16 bites processzorok (pl. a C-64 6510-ese volt 8 bites, ami azért nem egy XT kategória). Az XT-ben e processzorok köré 8 bites adatbuszt és 20 bites címbuszt terveztek. A cikkben a tévedés az, hogy Parci szerint az XT-kben nincs 16 bites regiszter. Pedig van. Az összes regisztere 16 bites. Az egy dolog, hogy lehet némelyiket független 8 bites regiszterekként is használni, de lehet egyben is.
Némelyiket pedig csak 16 bitesen lehet használni.
Ami a cikk végkicsengését illeti azzal teljesmértékben egyetértek. Már évek óta ''szívunk'' ezzel az örökös kompatibilitási dologgal.

Zoltán

prohardver vendég

Emberek, teljesen igazatok van, nem is tudom, mire gondoltam, amikor megírtam a cikket, de nem néztem meg a dolgot (évek óta nem ASM-ezek)...

Szóval leemeltem a Master Class Assembly Language könyvet a polcról (jó poros volt), és persze az első oldalon ott van az XT részletesen.

Cikk javítva, tényleg szori. A cikk ''szándéka'' nem változott, se az aktualitása, de az XT-s rész tényleg nem stimmelt, valamiért összekevertem a 286-ossal (pedig ott már 24 bites memóriacím-tartomány, 16 bites protected mode és egyéb finomságok vannak... bár protected mode-ból real mode-ba már csak a 386-os tudott visszajönni #reset nélkül :D).

No, lényeg a lényeg, hogy az XT-s részt javítottam. Szori, mea culpa.

dicranum scoparium + genista pilosa = :)

Parci: nem az MMX volt az első (bár nem túl funkcionális) SIMD utasításkészlet az x86-osokban?

Amúgy az AMD egyetlen esélye, ha jó támogatást ad az architektúrája mellé, mert ha az Intel kellően megnyomja az IA64 programok fejlesztését (az Intel elég erős fejlesztő-supportban, ha jól tudom), akkor a tényleg lesz benne fantázia, és az AMD-nek lesz az elavult technológiája.

Már régóta nem mindig a jobbik győz, hanem a jobban támogatott (marketingelt?).

Department of Redundancy Department

Amúgy jó a cikk :)

Department of Redundancy Department

Nem kötözködni akarok, de ha már belekezdtem a dologba akkor nem szeretném ha további pontatlanságok maradnának abban a részben ami nekem a szakmám (amikor én assemblyben programoztam, akkor még XT/286 gépek voltak). Szóval az XT ''processzor'' nem 8/16 bites, hanem 16 bites. Éppen ezért sohasem voltak 8 bites programok XT-n hanem a kezdetektől fogva 16 bitesek voltak. Az AL és AH regiszterek csupán megkönnyítették a programozók életét, ha 8 bites adattal akartak dolgozni, de az AX regiszter az XT kezdetétől fogva rendelkezésre állt. Az XT elött talán volt valami 8 bites PC, valami PC Junior nevű dolog rémlik, de ahhoz már én is túl fiatal vagyok. Amúgy tényleg jó a cikk és valóban az MMX volt az első SIMD.

Zoltán

prohardver vendég

Ha nulláról indult jó 64 bites procit akartok látni, akkor ott az Alpha, már ameddig még létezik. :) ).

Az Intel jelenlegi 64 bites procijaiban szerintem a legelrettentőbb a fogyasztásuk, ha jól emlékszem vmi. 130W környékén van, ehhez képest még egy ThunderBird is jégkockatartó. :D

A 64 bites prociknak meg sok helyen lehet létjogosultsága, nem muszáj feltétlenül az adatbáziskezelésre gondolni - 64 biten címezhető virtuális memória akármilyen fileműveletnél jól jöhet, pl. videószerkesztés, ami így kapásból az eszembe jut.

A SIMD dolgokra visszatérve: ilyet meg az UltraSPARC és az Alpha már akkor tudott, amikor az Intel még csak nem is álmodott róla, csak nem csaptak neki olyan eszement hírverést, mint az MMX-nek.

ldm start-reconf primary

Nekem tetszett a cikk. Mielott agyonfikazzuk a 64bit-et gondolkodjunk el azon, hogy anno a volt ha jol emlexem egy pentium pro.... ami szinten a hagyomanyokat akarta megszakitani (nem nagy sikerrel) A szamitastechnika tul nagy terulet ahhoz, hogy egyszeruen csak ugy atlojek 64-birte a dolgokat... Ez alatt azt ertem, hogy eloszor ugy is olyan procik fognak befutni amik futnak a regi 32-bites kodokkal is. Elso lepesben a sebesseg megorzese erdekeben valoszinuleg a koznep a 32 bit + kiterjesztett 32 bit (64)-es procikat fogja szeretni hiszen igy futnak a jelenlegi programok a leggyorsabban. Aztan majd jonnek a 64 bites procik amik kivu/belul azok de leemulaljak a 32 bitet.. aztan mar csak pure 64 bit lesz. Na az utolso lepes a legnehezebb ui. onnantol kezdve mar tenyleg nem futnak a regi dolgok. Az emberek meg szeretik ha a gepuk tudjak futatni a regi programokat ugye... ordogi kor. (meg jo hogy nem vagyok tervezo stb.. :DDD )
Mire jo a 64 bit? Szerintem pl. Nasa kimondottan elvezni az urkutatashoz jo lehet a nagy teljesitmeny. Pl. a seti program is gyorsabban haladhatna ha csupa 64 bites procit hasznalnanak a userek. A kutatasokra lenne eloszor jo mint eddig is minden uttoro. Aztan jonne a katonai kutatasok aztan leszallingozna az egyetemekre majd a userekhez az elony mint eddig mindig. Az, hogy 64 bitre nehez ''ujratanulni'' programozni az tuti. Lehet, hogy az intel belebukik ebbe a kiserletebe es az amd veszi at a vezetest (ez nekunk szimpla usereknek valojaban tok8) de elobb utobb o is bele fog utkozni ugyanebbe a visszafele kompatibilitasi problemaba az tuti. Mondok erre egy erdekes dolgot: a play station 2 tartalmazza teljes egeszeben az 1-et is... igy futathatoak rajta a ps1-es gamek is.... magyarul 2 hardware van benne. Lehet, hogy ez lesz a kovetendo pelda???

Zoltán, picit átfogalmaztam a cikket, most már szerintem igazán polírozott a cucc :). A pontatlanságokért elnézést kérek, mindez azért is kínos, mert jómagam is sokat nyúztam az XT-t, mielőtt átnyergeltem a 386-osra (na AZ processzor... az első igazi :D... v86 mode, normális protected mode, 32 bites regiszterek, normális multitasking, stb, stb.).

dicranum scoparium + genista pilosa = :)

OK emberek van valami amit ugy hivnak, hogy Microsoft.NET, ami azt mondja, hogy hamarossan a szoftver legnagyobb resze JIT forditasban fog futni (IL aki ert a dologhoz), ami azt jelenti, hogy az IA-64 en native kod fog futni (IA-64) mivel a Microsoft meg nem is foglalkozik x86-64 Windowsal, meg az IA-64 verzio mar valosag, tehat azt jelenti, hogy ha nem terunk at Linuxra (ami csak akkor fog megtortenni, ha disznokat fogok latni repulni... :)), azt jelenti, hogy az Itaniumon 64 bites OS-en 64 bites applikaciok fognak futni, a Hammer meg csak ugy fogja ismet ugy mint annak idejen a 386-os meg 486-os szineszkedve utanozni a 16 bites elavult procikat. Na de en nem vagyok Intel rajango, csak igy all a dolog manapsag.

prohardver vendég

Igen ez jeses a PC azaz az IBM eslo microgepe az XT elott az XT ugyanis eXtended Technology az is 16 bites gep volt (Intel i8088) procit hasznalt, ami csak abban volt 8 bites, hogy 8 bites volt neki az adatszelessege valahogy ugy mint ahogy az Amigaban, Macban es Atariban talalhato Motorola 680xx procik voltak csak hogy itt adolog 16/32 allt nem pedig 8/16 - on. Regi szep idok akkor csak mi szakertok hasznaltunk szamitogepeket, ma pedig aki volt Word meg Excel kurzuson, mar felviszi, hogy tud valamit. Meg ma is vigyazom az 5.25 inches diszkettakon a parszaz vagy esetleg parezer bajtos dolgokat amit assembleren irtam. Higyetek el mukodnek meg ma is Windows XP allat, nem epp minden, de nagy resze. Ez juttatja eszembe azt az 1018 bytos sakk programot amit abban az idoben egy ''pihent eszu'' amerikai pasas irt, nem eppen eros de sakkozni tud! Szeretnem latni a mai nagy ''SZAKERTOKET'' csinaljanak valami hasonlot!

prohardver vendég

Az Alpha ma az Intel tulajdona a mernokok most az Intelnel dolgoznak, figyelj majd oda az Itanium lessz az uj Alpha, csak nem most, most meg csak beta proci, az Alpha is volt beta proci, csak akkor meg nem beszeltek rola, az Itanium meg mar ugy ma nagyon ki van dumalva, de tulajdonkeppen majd csak a harmadik generacio lessz a bomba! Itanium = Aplha + HP + Intel + meg egy csomo cucc amit azelott meg nem tudtak, csak ki kell varni a veget!

prohardver vendég

Az Intel-nek nem kell licencelni az x86-64 technologiat, mert az egy szabadon felhasznalhato dolog, akar en is epithetnek vele processzort. Amikor a Transmeta ''licencelte'' a cuccott, az tulajdonkeppen csak azt jelentette, hogy hasznalni fogjak. Senki nem fizet senkinek semmit.

andropov

A cikk jó, de - egy laikusnak, mint nekem - tényleg vicces, hogy egy cég 1 M $-t és 7 évet szán egy olyan procira, amit már sok cég jól és sikeresen megcsinált, majd amikor nem jön össze neki és bukik az IA-64, kilóra megvesz egy kész architektúrát (Alpha). Gondolom majd fogja az Alphát, rászitázza az Intel logót és elnevezi IA-64 rev2-nek, majd kijelenti, hogy ''milyen fasza, egy-két dolgot még csiszolgattunk a procinkon és máris olyan jó lett, mint egy Alpha''

Use the force, Dude !

Talán kissé sarkosan/sarkítva fogalmaztál... :D

Aki a villamos alatt fekszik, annak nem természetes a mosolya.

Az Intel-nek ott van a kezében a 64-bites technológia, úgy hívják, hogy Alpha. Ha az Itanium project bedöglik - és úgy látszik bedöglik - kiadhatják az Alpha EV8-at ''Itanium-II' néven. Persze ezt el kell hinteni valahogy marketing dumával, hogy miért lesz jó a ''régi'' Itanium vonal megölése.

prohardver vendég

guest (#27)!

Ugye ezt a Word-Exceles dolgot nem nekem szántad?

Az én ASM programjaim spec egyáltalán nem mennek Windows alatt, hiszen CPL0 utasításokat, FLAT (4GB) memóriacímzést és v86-pm-rm módot vegyesen használtak. De szerintem az XT-s programok nagyrésze sem megy XP alatt... (vagy még az XP-ben is van DOS?)

dicranum scoparium + genista pilosa = :)

Abszolúte nincs... csak emulálja... :DD

Aki a villamos alatt fekszik, annak nem természetes a mosolya.

Akkor viszont azt csak és kizárólag V86-os módban teheti, hiszen nem engedheti meg, hogy igazi real mode-ban menjen a rendszer, mert akkor bármilyen program egy utasítással hasba akaszthatja (na jó, kettő: CLI, HLT).

A V86-os mód viszont elég sok dologban különbözik a Real Mode-tól, bár kétségtelen, hogy egy MOV AX,DI ugyanúgy hajtódik végre... (de az interrupt hívások, és persze az összes védett utasítás már nem). Szóval akkor meglepődnék, ha a régi ASM programok nagyrésze működne módosítás nélkül...

dicranum scoparium + genista pilosa = :)

Egy-két apróság:

Mire is kell a 64 bit, illetve miért nem lehet teljesen elhagyni a 8 bitet?
Egy olyan szoftver, ami kis adatokkal dolgozik, nagyon sok fölösleges adatot fog mozgatni a 64 biten akár a 32-höz képest is. Akkor lenne létjogosultsága a tiszta 64 bitnek, ha nem kellene 8 bites ASCII kóddal dolgozni pld. Teljesen fölösleges műveletekre van szükség, hogy a 64-ből kimaszkolják, feltöltsék, visszaírják a 8 bitet. És gondolom, hogy lehetne még példát találni.

Régóta foglalkoztat a kérdés, hogy hogyan lehetne megszabadulni a 8/16 bites világ nyűgjeitől. Mi kellene ahhoz, hogy a jelenleg PC néven futó eszközökben végbe mehessen egy olyan változás, ami kicsit pozitívabb jövőképet fest. Tényleg elég gáz, ahogy a Hammer regiszterei kinéznek, de a visszamenőleges kompatibilitás miatt kell...
Az Intel ötlete, hogy eldobja a korábbi vonalat, és egy teljesen tiszta architektúrát fejleszt, önmagában jó ötlet. Csak túl nagyot haraptak. Ha előbb megcsinálják 32 biten (megfelelő előrelátással), akkor már régen élvezhetnénk az előnyeit és könnyebben léphetnének át annak a 64 bites megfelelőjébe. De ők nem az otthoni piacot célozták meg, és csináltak egy iszonyatosan drága, nulla támogatottsággal rendelkező procit. Szerintem bukta. Ha megcsinálják 32 biten, olcsón, akkor nyertek.

Egy kicsi ASM, ha már mások is megtették:
ahhoz, hogy rendesen ki lehessen használni a 32 bitet, vagy akár a 64-et, kell a lehetőség a regiszterek megfelelő használatához. Az AMD megoldása nem ilyen, egyszerűen a régi módot követik, ami természetesen megfelel a körülményeknek. (Ebben szerintem az Intellel meg kellene egyezniük a jövőről:)
Naszóval, ha nekem egy 64 bites procit kellene terveznem, akkor a regiszterek felső részéből nem csak egy shift és egy maszkolás után lehetne elérni a megfelelő biteket. Ez igényli a címzési módok teljes megváltoztatását.
Egyszerűbb esetben 8 bitenként, fejlettebb módszerrel bitenként is címezhetőnek kellene lenniük. Valahogy így:

mondjuk ''R1'' 64 bites regiszter 2. 8 bitje R1[6] - (0-7-ig visszafelé számolva:), vagy a 2. és 3. 8 bitje R1[6,7], a bonyolultabb módon bitenként R1[43,10] azaz a 43. bittől 10 bites adat. Az adott műveletet ezen lehet végezni, és nem olyan nehéz a magot felkészíteni ilyen funkciókra.

Ez csak az alap, viszont ez lazán magában hordozza az x86 emulálásának lehetőségét!
Aztán, hogy valójában mit lehetne ebből kihozni, azt nem tudom, sajnos nincs rá párszázmillió Euro-m, de hogy jobb lenne, mint az IA64 az biztos:)

Aki tud, és tudja hogy tud, az veszélyes. Tőle féljetek. Aki tud, és nem tudja hogy tud, az bölcs. Tőle tanuljatok. Aki nem tud, és tudja hogy nem tud, az okos. Őt tanítsátok. Aki nem tud, és nem tudja hogy nem tud, az hülye. Őt hagyjátok ..

Nagyerekek, ha itt mindenki összedobja a védett módú 32 bites kódjait, akkor még egy oprendszert is összehozhatunk előbb utóbb. Pedig én annó a sötét 91-es év elszigeteltségében azt hiteem, hogy rajtam kívül más nem fejleszt védett módban (DPMI nélkül:). Ez első progimat a CGA videomemóriába töltöttem fel, mert ott tudtam biztosan, hogy hol kezdődnek a leíró tábláim :) olvastam, hogy a végrehajtás átlag 10%-al lassab a folyamatos szegmens ellenőrzések miatt, aztán a program e helyett 1/10-ed sebességgel futott (valami beepegés volt, de már védett módú). Később kellett rájönnöm, hogy a videomemória nem túl ideális hely programok futtatására :)
Ge.

Ha akarod kuldok 1-2 ASM programot amely dolgozik XP - alatt. A dolog csak annyiban van, hogy telyesen legalisan legyenek irva, itt azt ertem, hogy nincsennek nemdokumentalt instrukciok, meg trukok!

prohardver vendég

Inkább egyszerűsítve, nem akarok sokat gépelni :)))

Use the force, Dude !

Viccet félretéve: egyik szemem sír a másik meg nevet. :(
1. Épp' eleget szívtak a felhasználók mert egy csomó eltérő számítástechnikai platform létezik/létezett és ugye a ''közös nevező'' kialakítására csak akkor került sor (ha!), amikor muszáj volt (a piac kikényszerítette...). Ráadásul drága...
A fejlődés üteme rettentően felgyorsult, az átlagfelhasználó alig tudja (ha egyáltalán tudja) követni.
2. A monopóliumok kialakítása mindig veszélyes, többek között azért, mert a monopólium birtokosa nem mindig veszi figyelembe a felhasználók kéréseit (--> nem követjük, hanem csináljuk a piacot!). Ennek következménye, hogy a fejlesztések üteme lassulhat, illetve egyes elemei ''elsüllyed(het)nek''. Nem a piac (gyakorlat, használhatóság), hanem a monopólium birtokosa dönt(het) a fejlesztésekről, azok irányáról, ''életképességéről''. Sajnos előfordulhat, hogy abszolút tévesen teszi ezt (a mi szempontunkból).

Aki a villamos alatt fekszik, annak nem természetes a mosolya.

BadGe, nekem van egy 5-600KB forrású, saját DPMI kernelt tartalmazó pmode kernelem, v86-real-pm kapcsolásokkal, interrupt reflektorokkal, xms-vcpi-dpmi kompatibilitással.

Filekezeléssel sosem foglalkoztam, illetve az egész projekt befejezetlen lett :(.

dicranum scoparium + genista pilosa = :)

A kérdés az, hogy mi használható fel jobban: 8 db 8 bit-es, 4 db 16 bit-es, 2 db 32-bit-es, vagy 1 db 64 bit-es végrehajtó egység. Ez nyilván a feldolgozandó adatok jellegén múlik. Manapság döntően a 16/32 bit-es adatok feldolgozására van szükség (bár szaporodik a 64 bit-es adatok száma is), így jobban járhatunk sok 32 bit-es végrehajtó egységgel, mint fele annyi 64 bit-essel. (A 64 bit-es memóriakezelést így is meg lehet oldani.)

prohardver vendég

Nem egeszen ide tartozik, de nekem van egy 100KB asm.codom (nem en irtam) amit
FLAT mode alatt megy. At kellene irnom
pl. WinAsm-ba. A proggy maga nem
CPL0-as, FPU hasznal (de azt rendesen).
E proggy kapcsan nekem inkabb az
vetodik fel, hogy nekem inkabb szuksegem
lenne 4-8-10 procira mint egyre.
A multiprocesszoros rendszerek dragak,
pedig az lenne az igazi.
A magam reszerol AMD parti vagyok,
remelem lesz ''olcso'' 4-8 procis
rendszere.

Az kellene amit a SuN + Trasmeta
kitalalt sok-sok prociba :)))

XiX/PsychoMix

Valaki mondja már el, miért kellene az Itaniumnak x86 kódot futtatni? Az UltraSPARC-on sem fut x86 kód, sem a PA-RISCen, Power-en, MIPS-en, stb. Csak azért, mert az van ráírva, hogy Intel? Ehh...

prohardver vendég

Nem kell. Csak arra gondoltak a kollégák, hogy az eddig eladott cca. 2500 db (és ebből 2000 db az blablabla...) az nem igazán hatalmas teljesítmény még a nagy-kiszolgálók piacán sem és ezért talán nem ártana, ha kezelne némi átmenetet... :D
Persze amúgy is nonszensz az egész, hiszen az Itanium ára kb. 1300-4500$ között skálázódik.

Aki a villamos alatt fekszik, annak nem természetes a mosolya.

miért nonszensz? egy 833 MHz-es Alpha EV68 proci 4 MB cache-sel kb. 8000 dollár (nyolcezer)

prohardver vendég

Nem az ára nonszensz, hanem az (legalábbis egyelőre ...), hogy munkaállomásban történő felhasználását ''vizsgáljuk''.

Aki a villamos alatt fekszik, annak nem természetes a mosolya.

Kedves guest #26! Mióta szokott bármilyen Microsoftos szoftver futni?:))

En meg nem lattam Officet lefagyni meg godhos Windows 95/98 on sem, XP-n pedig meg le sem tudod fagyasztani meg akkor sem a szarasig ki nem allod a Microsoftot. MICROSOFT IS THE BEST OF ALL TIME AND THE SECOND PLACE ... SOMEONE HAVE TO BE BORNE YET TO EARN THE SECOND PLACE!

prohardver vendég

hé! #49
mielőtt ilyen nagy lenne az arcod, hogy itt microsoftozzál, azért próbálj meg előbb beilleszteni mondjuk 1 3MBos TXTfilet a wordbe, és nézd mi lesz...

értelmező késziszótár :: rekurzió --> lásd : rekurzió