"Nocona"/AMD64 deler samme bug

[Torbjørn]

jeg måtte hvertfall lese både artikkelen og denne tråden før jeg ble sikker på at det ikke var en bug i AMD64

[Simen1]

Incorrect physical address size returned by CPUID instruction

Problem: The CPUID instruction Function 80000008H (Extended Address Sizes Function) returns the address sizes supported by the processor in the EAX register. This Function returns an incorrect physical address size value of 40 bits. The correct physical address size is 36 bits.

Men er ikke EAX Intels tidligere måte å støtte mer enn 4GiB, ved å veksle mellom "4GiB-grupper" av minne? Altså den metoden intel har brukt helt siden P6-kjernen (Pentium Pro). Det er jo denne metoden som benyttes når f.eks eksisterende Xeon MP-systemer støtter opp til 64GiB.

 

Så vidt jeg forstår så er det skal CPUID-funksjonen returnere hvor mange bit adressering som er mulig. I gode gamle 32bit modus støtter nokona 64GiB (36bit) gjennom EAX. Jeg tipper at den støtter 40bit (1TiB) i EM64T-modus til tross for at dette ikke har vært poenget i artikkelen. For å oppsummere hva jeg tror:

* I 32bit modus støtter nocona 36bit adressering men oppgir feilaktig 40bit.

* I 64bit modus støtter nocona 40bit adressering og oppgir riktige 40bit.

 

Eller er jeg på bærtur her?

 

PS. Jeg kunne kanskje kalt EM64T for iAMD64 men lot være. AMD har tross alt hentet svært mye fra intel før. (Særlig den gangen AMD solgte intel-CPU'er på lisens fra intel (hint: alt fra 4004 til 486))

[blackbrrd]

Ifølge diverse andre news-sites så er det en dokumentasjonsfeil fra Intel sin side (de sier den har 40 bit til adressering, det er 36 bit, i tillegg til at prosessoren rapporterer 40 bit adressering, mens den skulle rapportert 36 bit.

 

(Amd sine prosessorer støtter 40 bits adressering, rapporterer dette og dokumentasjonen viser dette. - ihvertfall slik jeg har forstått det.)

 

Det er ingen feil med AMD sin prosessor og utsagnet til el-asso viser hvor dårlig overskriften passer til storyen.

[kindings]

Dersom det dere sier er riktig(noe jeg renger med det er) så er jo dette en ren Intel feil, så hvorfor blande AMD opp i det? I såfall er dette svakt av kilden bak artikkelen som hw.no har brukt(og forsåvidt av hw.no som har laget artikkelen uten å sjekke). Virker som om mange der ute er desperate etter å "finne" feil/mangler ved EMT64 i disse dager.

 

* I 32bit modus støtter nocona 36bit adressering men oppgir feilaktig 40bit.

* I 64bit modus støtter nocona 40bit adressering og oppgir riktige 40bit.

 

Høres rart ut ettersom den skal kunne kjøre 32bit og 64 bit parallelt etter det jeg har forstått?

 

Utover dette er jeg faktisk fristet til å si meg enig med Dollar rundt Intel og X86-64. Det er flere år siden vi hørte om Yamhill, ett prosjekt de avsluttet av en eller annen grunn(regner med EMT64 hvertfall delvis er bygget på yamhill). Mulig det lå mer bak den avgjørelsen enn det som er kommet frem.

Endret 15. juli 2004 av kindings

[ATWindsor]

Man kan jo alltids spørre seg om Intels tilsynelatende dårlige 64-bits implementering er gjort med vilje:

 

Will Intel Kill x86-64 By Supporting It?

 

Tanken har faktisk slått flere her (me, that is).

 

Deres engasjement for x86-64 virker ikke særlig entusiastisk - men til deres forsvar må jeg si at på desktop seg jeg heller ikke poenget (for annet enn markedsføringsverdien). Da synes jeg NX-bit/XD er mye mer innovativt og brukerorientert

Det tror jeg ikke er tilfellet personlig, det er for dristig, potensiale for å tape penger er stort, og 64-bit er allerede ganske populært.

 

AtW

[ØysteinI]

Høres rart ut ettersom den skal kunne kjøre 32bit og 64 bit parallelt etter det jeg har forstått?

 

Utover dette er jeg faktisk fristet til å si meg enig med Dollar rundt Intel og X86-64. Det er flere år siden vi hørte om Yamhill, ett prosjekt de avsluttet av en eller annen grunn(regner med EMT64 hvertfall delvis er bygget på yamhill). Mulig det lå mer bak den avgjørelsen enn det som er kommet frem.

At en CPU kan utføre både 32-bit og 64-bit instruksjoner, betyr ikke at den nødvendigvis kan gjøre det samtidig.

 

x86 veksler allerede idag mellom 16-bit og 32-bit... og 8-bit modus om jeg ikke tar helt feil. Grunnen til at man brukes "modus", er å sikre bakoverkompabilitet. Et 16-bit DOS-program skal bare oppdage de delene av CPUen som fungerer i 16-bit. Det ville jo være totalt meningsløst å ha divisjon med 32-bit tall tilgjengelig for et 16-bit program...

 

Så med AMD64 er hele 64-bit delen "gjemt" til man spesifikt "skrur dem på" under boot. For dagens 32-bit OS, så vil de tro at de kjører på en ren 32-bit CPU, siden de ikke "skrur på" 64-bit delene av CPUen.

 

Hvis så CPUen skal veksle mellom å kjøre 32-bit og 64-bit kode, vil den rett og slett bytte om fra å være en 32-bit CPU til en 64-bit CPU og tilbake igjen til 32-bit. Sånn vil den gjøre, for å sikre bakoverkompabilitet. HyperThreading for Xeon EM64T vil nok ha som krav at BEGGE trådene som tildeles CPU-tid samtidig opererer i samme modus. Tør vedde begge sokka mine på at HT ikke fungerer med en 16-bit tråd og en 32-bit tråd heller... selv under et 32-bit OS.

[HEE]

hehe..

dette liker jeg litt ... så nå kan de gutta som trodde "de store intel" aldrig gjør feil og hermer.. jekk dere ned et par hakk er dere snill..

 

så kanskje fol kjønner at det er ikke bare Amd som har litt "problemer" en gang i blandt.

[Tanguero]

Er det noen god grunn til at ikke artikkelen har endret overskrift enda? Samtlige her har kommet til samme konklusjon om at det ikke er snakk om en felles bug, så da er det litt merkelig at det blir stående.

 

Har hw.no aksjer i intel?

[ZyberZone]

Hmmm, her er det no muffins?

[Martin Lie]

Jeg reagerte også umiddelbart på overskriften, og begynte å lure på om jeg hadde feiltolket nyheten jeg leste på TheInq for en dag eller to siden. Men siden det viser seg at det er artikkelforfatteren som har misforstått, så bør denne overskriften endres ettersom den er direkte feil.

 

Det er uansett litt snodig å si at det er en bug i AMD64, ettersom det bare er en spesifikasjon (for et instruksjonssett). Det er hvertfall som regel kun bugs i implementasjonen (dvs. prosessorene)...

 

Endret 15. juli 2004 av Pureblade

[Kimble]

Usedvanlig dårlig overskrift da..

 

Tror intel med vilje har implentert en mangelfull 64bit støtte for å ødelegge for amd sine prosessorer. Om jeg ikke tar helt feil mangler intel sine prosessorer noen av amd's intstruksjoner (som sikkert gir bedre ytelse). Når software selskaper kompilerer programmene sine velger de sikkert å kompilere de slik at de kan kjøres av begge prosessorene og dermed blir endel av instruksjonene i amd prosessorende stående ubrukt.. Er ikke helt sikker på dette så skyt meg hvis jeg tar feil

[Revox]

Ja se og få skiftet artikkel navnet!

 

Det er bare tull fra ende til annen!

 

Forhåpentligvis vil software produsentene legge inn støtte for den raskeste prosessoren som ganske sikkert er AMD sin.

[Opteron]

Fy Heleveten for en elendig og missvisende overskrivt.

 

 

Da er det vell noe i at man ikke skal drikke og jobbe samtidlig, viss man ikke behersker å gjøre 2 ting samtidlig.

Eller at det datt noen hundrelapper i postkassen fra *ntel

[G]

Høres rart ut ettersom den skal kunne kjøre 32bit og 64 bit parallelt etter det jeg har forstått?

 

Utover dette er jeg faktisk fristet til å si meg enig med Dollar rundt Intel og X86-64. Det er flere år siden vi hørte om Yamhill, ett prosjekt de avsluttet av en eller annen grunn(regner med EMT64 hvertfall delvis er bygget på yamhill). Mulig det lå mer bak den avgjørelsen enn det som er kommet frem.

At en CPU kan utføre både 32-bit og 64-bit instruksjoner, betyr ikke at den nødvendigvis kan gjøre det samtidig.

 

x86 veksler allerede idag mellom 16-bit og 32-bit... og 8-bit modus om jeg ikke tar helt feil. Grunnen til at man brukes "modus", er å sikre bakoverkompabilitet. Et 16-bit DOS-program skal bare oppdage de delene av CPUen som fungerer i 16-bit. Det ville jo være totalt meningsløst å ha divisjon med 32-bit tall tilgjengelig for et 16-bit program...

 

Så med AMD64 er hele 64-bit delen "gjemt" til man spesifikt "skrur dem på" under boot. For dagens 32-bit OS, så vil de tro at de kjører på en ren 32-bit CPU, siden de ikke "skrur på" 64-bit delene av CPUen.

 

Hvis så CPUen skal veksle mellom å kjøre 32-bit og 64-bit kode, vil den rett og slett bytte om fra å være en 32-bit CPU til en 64-bit CPU og tilbake igjen til 32-bit. Sånn vil den gjøre, for å sikre bakoverkompabilitet. HyperThreading for Xeon EM64T vil nok ha som krav at BEGGE trådene som tildeles CPU-tid samtidig opererer i samme modus. Tør vedde begge sokka mine på at HT ikke fungerer med en 16-bit tråd og en 32-bit tråd heller... selv under et 32-bit OS.

Det virker ulogisk at hovedkortet vet hvilket OperativSystem du kjører på din harddisk da. :!:

 

Er du sikker på at BIOS får vite om den skal boot'e med 32-bit, 16-bit eller 64-bit? Det jeg mener med å pirke i dette er at du selv sier:

 

"Så med AMD64 er hele 64-bit delen "gjemt" til man spesifikt "skrur dem på" under boot. For dagens 32-bit OS, så vil de tro at de kjører på en ren 32-bit CPU, siden de ikke "skrur på" 64-bit delene av CPUen."

 

Ja, det er "mystisk" dette med hvordan AMD har fått det til. Eller imponerende.

 

Noen som kan forklare oss hvordan og hvor dette skjer. Kanskje noen kunne skrive en artikkel om dette hos HW.no hvis de tør å begi seg inn på "fagfeltet". Synes det hadde vært interessant å lese om hvordan det hele fungerer.

 

Jeg hadde inntrykk av at CPU'en er designet for å veksle "smertefritt" mellom 32-bit og 64-bit bruk av instruksjoner. Men jeg er jo ganske blank om temaet selv.

Endret 16. juli 2004 av G

[snorreh]

Man kan jo alltids spørre seg om Intels tilsynelatende dårlige 64-bits implementering er gjort med vilje:

 

Will Intel Kill x86-64 By Supporting It?

 

Tanken har faktisk slått flere her (me, that is).

 

Deres engasjement for x86-64 virker ikke særlig entusiastisk - men til deres forsvar må jeg si at på desktop seg jeg heller ikke poenget (for annet enn markedsføringsverdien). Da synes jeg NX-bit/XD er mye mer innovativt og brukerorientert

Tja, 64-bit betyr her ikke bare en økning av fysisk minne men også en dobling av antall registre (fra 8 til 16) som de fleste programmer vil dra stor nytte av og spesielt til krevende oppgaver som f.eks. rendring, videoredigering, enkoding og ikke minst spill

 

Ifølge Anandtech så vil trolig 64-bits ytelsen til EM64T-prosessorer være merkbart lavere enn AMD64-prosessorer:

http://forums.anandtech.com/textthread.cfm...tmsgid=14907639

As far as Nocona goes, we won't have a review at launch but we're working on setting up a test suite specifically for those purposes. It's sort of ironic that the comparison of the two x86-64 chips out there will be best done under 32-bit applications

 

Under 32-bit apps the situation should be much like Athlon 64 vs. Prescott, under 64-bit scenarios I don't expect things to change too dramatically. But remember that Prescott (and thus Nocona) only has 32-bit ALUs so while it can do 2 x 32-bit integer operations per clock through each of its two "double pumped ALUs" per clock, in 64-bit its integer throughput through the double pumped ALUs will essentially be halved.

Endret 16. juli 2004 av snorreh