» »

strani: 1 2 3 4 5

nietka ::

@Thomas: smeh, se opravicujem, ce niste tistega "le cevlje sodi naj kopitar" razumeli. Niste namrec racunalnicar, se manj dr. racunalnistva in informatike, da bi lahko meni ali komurkoli drugemu solili pamet o teh receh. Predvsem, ker ne kazete nikakrsne sirine obzorja, splosne razgledanosti ali volje in zelje nauciti in sprejeti se kaj drugacnega.

Ne delam se zrtve, zelim razjasniti stvari, ki se ticejo muzeja, za katerega sem odgovorna kot tudi razstave, ki jo pripravljam.

Upam si seveda staviti, da Vas ne bo niti blizu Kiberpipe, kaj sele, da bi si prisli razstavo namenoma ogledati - v tej temi pa ste vse prevec glasni in nadlezni.
Great warrior? Wars not make one great.

Thomas ::

Ne vem, kaj je bil pravzaprav razlog zelenega odtenka. V resnici sem zelo hitro izmenjeval vzorce po ekranu, zato sem tudi rabil assembler. ASCII 176, 177, 178 - tam nekje, tiste tahrapave "dilce", ki so ble, sem "polagal" po ekranu in za njimi se je vlekla jasna zelena sled.

Če je bila samo prevara očesa, pa ne vem. Mogoče da je bila, mogoče da je fosor svetil zeleno zaradi stresa. Ne vem.
Man muss immer generalisieren - Carl Jacobi

Brane2 ::

Bi blo zanimivo vedeti. Ranvo sedaj rezmetavam podatke o naravi vida, raznih efektih itd.

Če boš mel še kaj takega, poročaj...
On the journey of life, I chose the psycho path.

Brane2 ::

Mogoče pa je bil beli fosfor mix treh ( rdeči, zeleni in modri) od katerih so imeli vsi različno persistenco.

Mogoče je celo,d a je proizvajalec namenoma dal daljši zeleni fosfor, da bi bil zeleni tekst na črnem videti extra cool...

Pa si to probal samo na svojem ali še kakem drugem monitorju ?
On the journey of life, I chose the psycho path.

Thomas ::

Če ima še kdo kakšen delujoč ČB monitor z delujočim 286, lahko zadevo hitro reproducira, po moje.

Mogoče je bila samo varianta tega.

Imel sem samo en tak monitor na razpolago takrat. Drugi so bili zeleni ali amber.
Man muss immer generalisieren - Carl Jacobi

Matako ::

Ne vem, kaj je bil pravzaprav razlog zelenega odtenka. V resnici sem zelo hitro izmenjeval vzorce po ekranu, zato sem tudi rabil assembler.


Ne bi se rabil niti matrati - pri tovrstnih karticah je "hitrost izpisa" omejena z video hardverom in je dokaj nizka, tako da je bilo ponavadi cajta še in še. Govorimo o nekaj ducatov Hz (tipično 50-70) proti milijonom! Tvoj 286 sistem je tudi skoraj 100% imel t.i. 16-bit ISA vodilo, ki je običajno sinhro z CPU na bornih 8 Mhz, da ni bilo težav. Razen, če ni bila to ena izmed njih? Kakorkoli, tvoja "dvaosemšestka" se je večino časa izvajanja tvojega programa dolgočasila v čakalnih stanjih pri naslavljanju vodila. Dvomim, da je to povezano s procesorjem na kakršenkoli način.

V primeru, da res ni samo optična prevara (čisto možno!) je tvoj gfx trik verjetno veliko bolj povezan s samim monitorjem in grafično kartico. Predvsem kaki TTL monitorji (MGA/Hercules) so bili dostikrat čudni iz z vsakojakimi fizikalnimi pojavi in možnostjo proizvajanja artifaktov, podobnih tistim na TV, ki pa jih je itak super-počasno-tleči fosfor zvito zamazal.
Druga drznejša teorija bi bila v zvezi s tem, da je bil fosfor takrat celo v najkvalitetnejših ČB zaslonih še vedno navadno sranje in je v resnici potreboval nek čas, da je zažarel v beli barvi in je potem hitro preklapljanje signala zaradi haširanega vzorca in pomikanja vsebine mogoče delalo čudne stvari? Samo to dvomim...

V vsakem primeru je malo verjetno, da se bo dalo trik ponoviti, tudi če bo hw zelo podoben!

No mogoče ima ravno Kiberpipin muzej podoben hardver?

Kar si doživel tam v 80-ih je bil edinstven, neponovljiv trenutek v življenju - hrani ga, ker ga ne bo več nazaj :(

Mater, kar naenkrat se počutim star :(
/\/\.K.

Zgodovina sprememb…

  • spremenil: Matako ()

Zheegec ::

Sem ponosen lastnik dveh RISC procesorjev :)

Saj jih z lahkoto v trgovini kupiš, jaz jih imam cel kup doma, pa vsak navaden PC jih ima :)
Sicer lavfajo gori CISC kodo, ampak pustimo podrobnosti - x86 proci so že kar dolgo časa RISC, če gledamo notranje delovanje...
"božja zapoved pravi; <Spoštuj očeta in mater>,
ne govori pa o spoštovanju sodstva."
Janez Janša, 29.04.2014

MrStein ::

Če ima kompleksne ukaze, je CISC
Če laufa mikrokodo, je CISC.

(in oboje velja za x86)

Če pa imaš ti kako drugo definicijo pojma "CISC", pa na dan z njim.
Teštiram če delaž - umlaut dela: ä ?

WarpedOne ::

>> Če laufa mikrokodo, je CISC.

Povej mi EN omembe vreden procesor, ki ne laufa nobene mikrokode. Ti romantični časi so že zdavnaj minili. Najdeš jih le še v učbenikih.
What do you Think to Know?
Why do you Think you Know it?

MrStein ::

Kot sem rekel, podaj definicijo pojma CISC, kateri ne ustreza x86.
Teštiram če delaž - umlaut dela: ä ?

WarpedOne ::

Podaj mi omembe vreden procesor, ki ustreza definiciji RISC. Pa ne nek mikrokrmilnik s 100.000 tranzistorji. Splošno namenski procesor, ki se ga da programirat tudi v čem drugem kot assemblerju.

CISC je kratica za COMPLEX INSTRUCTION SET COMPUTER. Zmislili so si jo, ko so začel študirat o procesorjih z manjšim številom ukazov, kot pa je bila takrat splošna praksa. Temu novemu konceptu so pač zato rekl RISC = REDUCED INSTRUCTION SET COMPUTER. Če trdiš da obstaja absolutna definicja tega, kaj je kompleksno in kaj ni, me fejst zanima kakšna bi bla.

Tako CISC kot RISC kot VLIW pa še kaj že preživeta stvar - majo pomen v zgodovini, v sedanjosti pa bolj malo in vse manj. Še to, kaj je "pravi" 64 bitni računalnik ni čisto kristalno jasno. Danes so procesorji vse od zgornjega zato je edino merodajno le performance/price in performance/watt. Šteje le, koliko logike se da spravit v N tranzistorjev in kaj je tista logika sposobna spravit iz sebe. O lepotah rešitev se pa naj kregajo prfoksi na faksih, ki so itak financirani iz proračuna. Sanjarije, kako da bi bilo vse lepše na "pravih RISCih" so pa čiste sanje. PowerPC 601 je bil narjen iz nule po RISC principih in je pogorel. x86 is here to stay.
What do you Think to Know?
Why do you Think you Know it?

Loki ::

Me pa zanima kaj bo Intel spacal skupaj z Larabee (pa ne samo zaradi konkurence GPU-jem

tale larabee bi pa znal biti uspeh, ja. vsaj ce ga ne bodo matrale prevec latence in toplota.
I left my wallet in El Segundo

MrStein ::

WarpedOne, brez razburjanja. ;-)

Kot si rekel, ni mogoče x86 stlačit v kako "definicijo" (v narekovajih, ker kot si rekel, neke prave definicije ni) RISC-a. Ali CISC-a. Le na to sem opozoril.

Če pa se je treba odločit med enim ali drugim, bi _jaz osebno_ rekel CISC, ker:
- complex instruction set ? Seveda.
- reduced set ? Ne. (saj nasprotno, z vsako generacijo _dodajo_ instruction-e)
Teštiram če delaž - umlaut dela: ä ?

Jst ::

Larabee based računalnik bi znal delovati brez osrednjega CPUja. Ker Larabee naj bi bil GPGPU - General Purpose GPU. Shaderje bolj podobne x86 arhitekturi brez balasta, ki ga sedaj x86 procesorji nosijo.

Larabee, ker nima, oziroma ne bo imel, tako omejene instruction sete, kot trenutne shader enote, bi lahko prvi ponudil Raytracing v kakšni izmed future konzolah. Raytracing je pa final step to the photorealistic graphics.
Proton decay is a tax on existence.

BluPhenix ::

Podaj mi omembe vreden procesor, ki ustreza definiciji RISC.


ARM7TDMI je tak naprimer. Čisti RISC procesor pa precej omembe vreden. (V bistvu so vsi ARMi RISC).

WarpedOne, za veliko RISC procesorjev je med drugim značilno to, da za večino operacij porabijo en cikel.

Tako CISC kot RISC kot VLIW pa še kaj že preživeta stvar - majo pomen v zgodovini, v sedanjosti pa bolj malo in vse manj.


Za PCjaške visokonivojske programerje vsekakor, za embedded programerje pa vsekakor ne...

Še to, kaj je "pravi" 64 bitni računalnik ni čisto kristalno jasno.


Tisti, ki ima 64 bitni naslovni prostor?

Ne preveč ozko gledat na to, ni zdravo.
Podpisa ni več, ker so me poskušali asimilirati.

Zgodovina sprememb…

WarpedOne ::

Hja, sem mislu da teče debata okrog general purpose zadev - serverji, desktop, laptop.
ARMi so drug svet - embedded. Spodobilo bi se, da potem vsaj omeniš še njihove performanse, ki so na drugi strani prepada.

>> Tisti, ki ima 64 bitni naslovni prostor?

Torej trenutno AMDji niso 64bitni ampak so samo 48 bitni, ker je zgornjih 12 bitov naslova itak pribitih na 0? Ali so morda le 40bitni, ker je tolk placa za dejanski fizični naslov? Ali so morda kljub temu 64 bitni, ker podpirajo 64 bitne integerje? Ali so morda 128 bitni ker podpirajo tut 128 bitne operande?

>> Ne preveč ozko gledat na to, ni zdravo.

Morda bi moral upoštevat svoj lasten nasvet? :)
What do you Think to Know?
Why do you Think you Know it?

BluPhenix ::

Hja, sem mislu da teče debata okrog general purpose zadev - serverji, desktop, laptop.
ARMi so drug svet - embedded. Spodobilo bi se, da potem vsaj omeniš še njihove performanse, ki so na drugi strani prepada.


Hja tukaj nekako stalno teče debata o praktično vseh arhitekturah, ker se je jih je "primerjalo" med seboj. Če si se želel omejiti zgolj na PC platformo bi moral to lepo naznaniti.

Ni mi pa čisto jasno kaj si mislil s performansami ARMjev, da so na drugi strani prepada. Lahko bolj jasno to napišeš?

Torej trenutno AMDji niso 64bitni ampak so samo 48 bitni, ker je zgornjih 12 bitov naslova itak pribitih na 0?


Pribiti ali ne ... tam so. "Bitnost" procesorjev se je vedno nekako gledalo na to, koliko bitni naslovni prostor imajo. Potem so pa prišli programerji in so si izmislili neke svoje enote. Tudi Armi znajo premetavati 64bitna števila, pa so še vedno 32 Bitni.
Podpisa ni več, ker so me poskušali asimilirati.

Zgodovina sprememb…

nekdo123 ::

BluPhenix: torej je bil Z80 16 bitni in ne 8 bitni, ker je imel 16 bitni naslovni prostor?

WarpedOne ::

Hja tukaj nekako stalno teče debata o praktično vseh arhitekturah, ker se je jih je "primerjalo" med seboj. Če si se želel omejiti zgolj na PC platformo bi moral to lepo naznaniti.


Ne ne, nič me ne moti če na mizo vržeš Power procesor in njegov ISA in mal podebatiraš o njem. Malo čudno pa izpade če začneš peti hlavospeve RISC pristopu na podlagi nekega micročipa, ki je sicer sposobn spedenat par FFTjev v realtimu to je pa tut počas vse. Ne trdim da to delaš ti. Le pojasnjujem :)

Glede 64bitnosti:
Kriterij po katerem se je določevalo bitnost se je skozi čas spreminjal in se še bo. To, da je to velikost naslovnega prostora je bol tricky. Dejstvo je, da trenutni 64bitni x86 lahko naslavljajo le 48/40 bitov. Zraven upoštevat še mrtvo solato je malo brezveze. Kaj ustavlja nekega proizvajalca da namesto 12 fiksiranih bitov da zram še 64 drugih in trdi da ma 128 biten procesor. Boš še vedno trdil da tistih 76 na 0 fiksiranih bitov nema veza in da je to "pravi" 128 bitnik? A boš mogoče trdil da so bli P3 in P4 36 bitni? Koneckoncu so mel fizične naslove dolge 36 bitov. Vse skup je en tak mehek konsenz, ker fiksna definicija enostavno ni možna, brez da bi ven štrlelo kup primerov, ki bi te spravljali v zadrego.
What do you Think to Know?
Why do you Think you Know it?

BluPhenix ::

Malo čudno pa izpade če začneš peti hlavospeve RISC pristopu na podlagi nekega micročipa, ki je sicer sposobn spedenat par FFTjev v realtimu to je pa tut počas vse.


In po tvoje ARMi znajo samo to? Ha. Zanimivo, da poganjajo veliko večino PDAjev in pametnih telefonov zadnje čase. Res so bogi bogi :(

Seveda mu pojem hvalnice, saj so zelo uporabni in ni čudno, da so prevzeli trg. Z njimi delati je poezija praktično. Odkar sem se srečal z njimi mi niti na misel ne pride, da bi še kaj naredil s kakšnimi 8 bitniki ali čim podobnim, ker so tako poceni za to, kar ponujajo da nima smisla kaj dosti drugega uporabljati.
Podpisa ni več, ker so me poskušali asimilirati.

Zgodovina sprememb…

WarpedOne ::

PDA, pametni telefoni ipd so pa res polje kjer je potrebna huda računska moč. Komot ARMi super pašejo v takšno okolje, nikakor pa to ni nikakršen argument da bi lahko kar konkurirali x86 zverinam. Nekaj je, dokler je na prvem mestu performance/watt in imaš omejen rang razpoložljivih wattov. Čisto druga pesem pa je, ko je ta rang 10x al pa 100x višji. Takrat se ti odpre paleta možnih pristopov, kjer je vztrajanje na RISC dogmah čista bremza. Trg je to že dokazal.
What do you Think to Know?
Why do you Think you Know it?

Bistri007 ::

Samo ena hitra pojasnitev: eno je x86 arhitektura, drugo je PC arhitektura.

x86 je procesor, ki bi bil lahko tehnično zgrajen okoli arhitekture, ki ne bi bila kompatibilna z npr. Windows. Primer tega je EFI.
PC je po domače motherboard+procesor (IRQji, porti, DMA, BIOS, I/O podsistem, dostopanje do diska, $B800 text, $A000 grafika [Hercules, CGA, EGA, VGA, VESA])
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

Thomas ::

Se bojim, da je podrobna procesorska arhitektura nekaj zelo irelevantnega, kakor hitro tisti CPU zna dobro in hitro opravljati neke ključne operacije.

Če je nek set inštrukcij omogočen, potem niti sam fizikalni proces ki stoji za njimi, ni tako bistven. Sej, če se najde hitrejši in zanesljivejši - super. A tudi če se ne, delat se da.

Eleganca fiktivnih in bodočih procesorjev je bolj l'art pour l'artistično vprašanje, kot kaj drugega.

Napredek se dosega že desetletja in še se bo. Arhitektura je pa precej postranska tema.
Man muss immer generalisieren - Carl Jacobi

Thomas ::

Vprašanje, ki ga uporabnik zastavlja ponudniku procesorja, je pravzaprav preprosto. Kako hitro in zanesljivo in poceni, mi skonvertiraš tale bitni string v tale bitni string. Tko, eno neznansko število takih parov, kako mi to premašinaš? Rabm za svoje sedanje in bodoče sofvere. Če pa imaš kje vmontirane take ali drugačne "čudeže" not, me pa zanima en tolk, kot točna formula za zlitino za feltne. Samo, da je dobr.

Amen.
Man muss immer generalisieren - Carl Jacobi

Matako ::

Tukaj se s Thomasom zelo strinjam! Procesorska arhitektura ne samo da za uporabnika (programerja, celo dizajnerja sistemov) ni vidna in je v osnovi... nepomembna (razen v hitrosti, zmožnostih), načeloma naj bi mu bila tudi skrita, za nejgovo dobro ;)
Na ta način se prepreči, da bi uporabnik uporabljal finte, ki prehodu na drugo arhitekturo ne bi več delovale tako zelo dobro - gl. zgodbo spodaj. To je bil saj včasih, ko je bila izbira procesorjev manjša izredno popularen šport. Sam vem kako se je ročno optimiziralo x386 kodo, ki pa je kar naenkrat postala ne tako zelo optimalna na x486 (ker ima drugo arhitekturo in je timing izvajanja _zaporedja_ ukazov drugi) itd. itn.

Mogoče najbolj poučna zgodba te vrste je tista o prvem MacOS OS, pisanim posebej za MC68000. Celo največje mojstre, kot je bil Andy Hertzfeld včasih malo zavede želja po pretirani optimizaciji...

Kljub temu, da je Motorola zasnovala sicer strojno 16-bit 68000 kot naprej kompatibilni 32-bit procesor (ima 32-bit naslovne registre, med drugim) in kljub temu, da je uporabniški priročnik za MC68000 na veliko težil, da naj se smatra naslove izključno in samo kot 32-bit, se je Andy vseeno odločil, da je hardversko naslovljivih 16MB čisto dovolj in veselo uporabil zgornjih 8 bitov sistemskih kazalcev za svoje zlobne namene (razne zastavice).

Napaka! 68000 to ignorira, samo prvi modeli macov, ki so imeli pravi 32-bit 68020 kar naenkrat niso več pravilno delovali, ker so bili naslovi popackani!

Morala zgodbe: včasih je bolje manj vedeti o arhitekturi procesorjev!
/\/\.K.

Zgodovina sprememb…

  • spremenil: Matako ()

Brane2 ::

Ta fora z naslovi in packanjem visokih adres je v bistvu prisotna vsepovsod in je klasični tradeoff optimizacije- ali stvari upenališ najbolje kar znaš za sedanje razmere, ali pa žrtvuješ en kos optimalnosti za bodoče izzive.

Tipi, ki so optimizirali SW za 68000 so očitno zelo dobro vedeli kaj počnejo, a je pri njih prevagala sedanjost, ne nujno zaradi trapaste kratkovidnosti.

Čisto možno je,d a so hoteli imeti maksimalno hiter SW sedaj in razlog zakaj bi folku prodali upgrade za 68020/30/40/60 verzijo, ko bi jo folk hotel.

Kar se tiče filozofije "saj ni važen ISA in osnova corea, sam da je hitr pa da dela", bi se s tem dalo delno strinjati.

Tako kot so razširili x86, mu dodali periferijo in nabili MMX/SSE etc enote, bi lahko razširil katerikoli stroj, celo 6502 iz prastarega Commodoreja.

Do sem vse lepo in prav. Ampak take neoptimalnosti pomenijo nove zahteve pri razvoju čipa, kar pomeni več bugov, daljši razvoj, višje cene, večjo porabo za isti učinek in nižji plafon maksimalnega dosegljivega učinka po coreu.

Da se da iz drv narediti raketo, če imaš zadosti materiala zadostne kakovosti je jasno - x86 je dokaz za to.

Ampak sedaj prihajamo do trenutka, ko je raketa dosegla svoje omejitve in se snovalci vračajo k koreninam- k kakovosti osnovnih sklopov...
On the journey of life, I chose the psycho path.

MrStein ::

Thomas:
Vprašanje, ki ga uporabnik zastavlja ponudniku procesorja, je pravzaprav preprosto. Kako hitro in zanesljivo in poceni, mi skonvertiraš tale bitni string v tale bitni string. Tko, eno neznansko število takih parov, kako mi to premašinaš? Rabm za svoje sedanje in bodoče sofvere. Če pa imaš kje vmontirane take ali drugačne "čudeže" not, me pa zanima en tolk, kot točna formula za zlitino za feltne. Samo, da je dobr.

Amen.

Seveda.

Razen če ti inženir pove, da bo projekt v assembleru na X trajal dvakrat dlje in dražje, kot na Y.

Kar je seveda irelevantno, če se programira v višjem programskem jeziku.
Teštiram če delaž - umlaut dela: ä ?

MrStein ::

Bistri007:
x86 je procesor, ki bi bil lahko tehnično zgrajen okoli arhitekture, ki ne bi bila kompatibilna z npr. Windows. Primer tega je EFI.

EFI je zelo kompatibilen z Windows.
Teštiram če delaž - umlaut dela: ä ?

Jst ::

Optimizacije.

Intel je super izkoristil doooolg cevovod p4 in v njega stlačil t.i. HyperThreading. Tako smo optimizirali probleme, ki se jih je dalo paralelizirati. Recimo SQL server je pridobil 30%. For free. Ko pa so prišli pravi dual core procesorji, so bile pa te optimizacije še relevantnejše in ni bila potrebna niti ena sprememba arhitekture. Razen mogoče, če se je kdo preveč omejil na dejansko delovanje HTja, kjer je potem uporabil drugo nit on-demand, kjer se je splačalo. Tisti, ki se pa nismo omejili na dve niti in pustili threade, naj se kreirajo, ne glede na arhitekturo, nismo dosegli maximuma, ki bi ga lahko pri HTju, ampak sedaj na quad core in naprej, octo core, spet, ne bo potrebne nobene spremembe.

Tako je delno res, da je bolje, če programer ne ve prav dosti o underlying arhitekturi.

Jaz pa sem takrat bil navdušen nad HyperThreadingom, s prihodom dual in več core, pa še bolj, da je Intel izbral takšno strategijo. Pa čeprav P4ht dejansko ni bil sposoben paralelno izvajati dve niti. Drugo nit je samo vrinil v proste cikle svejega dolega cevovoda.



--
edit: post sem pisal "po epizodah," zato je mogoče malo čudna struktura.
Proton decay is a tax on existence.

Zgodovina sprememb…

  • spremenil: Jst ()

Bistri007 ::

Bistri007:
x86 je procesor, ki bi bil lahko tehnično zgrajen okoli arhitekture, ki ne bi bila kompatibilna z npr. Windows. Primer tega je EFI.

EFI je zelo kompatibilen z Windows.


Mr Stein, na EFI kompjuter ne moreš dati normalnih Windows XP. EFI podpirajo samo Windows za Itanium in Vista/2008 64-bit.
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

MrStein ::

Rekel si "Windows", ne pa "Windows XP".

(meni je vseeno, ne rabiš se razburjati)
Teštiram če delaž - umlaut dela: ä ?

Bistri007 ::

Imaš prav. Vendar sem mislil vse Windows, od 3.0, DOS, 95, 98, 2000, XP, 2003 (za x86/x64) in Vista 32-bit.
Itanuim pa tako ali tako ni x86 [ok, emulacija, samo je sedaj celo izklopljena]
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

Brane2 ::

Bump.

Sem še dvakrat prebral uvodnih 5 delov AMD X86_64 specsov. F**k.
Kdor pravi, da je x86 in nasledniki pa ja čisto cool, bodisi nima kaj dosti pojma o zadevah, bodisi je nek težek assembler taliban, ki trese optimizirano kodo iz rokava.

Seznam, stvari, ki totally,royally, mindboggingly suck-ajo na tej zadevi je verjetno daljši od prvega dela navodil ( ene 400+ strani brat bratu).

Kar pa se tiče argumenta "zakaj so potem prevladali na trgu", sedanji razvoj dogodkov kaže, da pravega trga ni in ga nikoli ni bilo.
Je samo Intel, ki s papirji nadzira ostale. Dovoljuje jim le minimum, ki je zadosti,d a ga industrija trpi, vse ostalo pa ubija.
On the journey of life, I chose the psycho path.

Zheegec ::

Ni nujno, je še backwards compatibility tukaj, zato pa Itanium ni ravno nek prodajni hit, čeprav je teoretično bistveno bistveno boljša arhitektura. Če bi pa Itanium prodrl na domači trg in prevladal nad x86, bi pa še tisto malo trga bilo konec. No cross-licensing...
"božja zapoved pravi; <Spoštuj očeta in mater>,
ne govori pa o spoštovanju sodstva."
Janez Janša, 29.04.2014

Brane2 ::

Pod "papirno kontrolo" mislim predvsem na x86 licenco, kjer s preprostim Instruction Setom efektivno preprečujejo drugim, da bi stopili na ta trg.

Stvar je extra patetična, ko se spustiš v branje in preučevanje x86 ISA in vidiš, da ta stvar ima kvečjemu _negativno_ vrednost.

Kot lahko vidimo te dni, ima celo AMD zelo omejeno licenco, ki jo lahko zelo hitro zgubi.
O težavah VIA-e, ki jih je imela z Intlom zaradi x86 čipov je bilo tudi veliko napisanega.

Mogoče bi bil čas za "sveženj antimonopolnih ukrepov" s strani EU pa še koga tudi za Intla...
On the journey of life, I chose the psycho path.

Brane2 ::

Kar pa se Itaniuma tiče, ni x86 performance njegov edini problem.

Njegov največji problem je zaprtost. Z njim je imel Intel v planu pobiti vso preostalo konkurenco in zasesti PC trg povsem sam.
Če ne bi bilo AMDja, bi mu to mogoče celo uspelo.

Licence za njegov ISA niso nameravali ponuditi nikomur.

Poleg tega pa že nekaj časa kaže, da misli razvoj iti v drugo smer - večje število relativno enostavnih coreov...
On the journey of life, I chose the psycho path.

BigWhale ::

Poleg tega pa že nekaj časa kaže, da misli razvoj iti v drugo smer - večje število relativno enostavnih coreov...


Kar pomeni samo to, da bomo v prihodnosti videvali vse vec programov, ki se trudijo paralelizirati svoje delo. Edino prav. Paralelizirat se da skoraj vse, kar dandanes pocne uporabnik.

Bistri007 ::

Brane, x64 se ne razlikuje veliko od x86. Nekaj neuporabnih ukazov so pobili (predvsem tiste za delo s segmentnimi registri). Meni je x86 naraven, drugih niti ne poznam. Par let nazaj sem šel gledat IA64 (Itanium) - to je šele zmešnjava. Ideja Itanija je, da z optimizirano kodo naredi paralelizem znotraj niti (en opcode, do trije samostojni ukazi). Ideja je s konca 90tih, sedaj je itak bolj aktualen multicore (Larrabee :)))

Se pa strinjam, da so razširitve, kot so MMX, SSEx grdo zakodirane. Samo je Intel z novim AVXom ubral prav elegantno rešitev :) (LDS, LES)

Meni se drugače zdijo tisti TSSji (task state segment), GDTji in Page tables veliko zakomplicirani od samega kodiranja ukazov (opcode) oz. asemblerja.
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

Brane2 ::

Se pa strinjam, da so razširitve, kot so MMX, SSEx grdo zakodirane. Samo je Intel z novim AVXom ubral prav elegantno rešitev :) (LDS, LES)


Razširitve ?!?
Cela stvar je inicialni drek, ki je evoluiral tako, da je fasal raka in so razširitve v bistvu metastaze.
Bljak.

Čisto tako nekaj biserov:

Cela stvar se je začela z 8008- 8 bitnim pi*kin dim CPUjem, katerega glavni in edini adut je bila unikatnost- konkurence ni bilo !
Nato je prišel njegov naslednik - 8080/8085, katerega edina prednost je bila cena, dokler ni prišel Z-80 in ga zgazil ko kamjon drek na cesti. Da o ostalih niti ne govorimo.

Nato je prišla 16-bitna generacija in intlov 8086. Ta je bil v veliki meri združljiv z 8080 in to je bil njegov cilj - prevzeti čimveč od predhodnika. Ta pa je bil penaljen nekako tako kot danes najmanjši mikrokrmilniki v PIC seriji-uporabiti čimmanj pomnilnika in biti čimcenejši. Rezultat je čuden skupek s kupom namenskih registrov in posebnih ukazov in "tajnih orožij", ki so mogoče nekoč bila videti cool na prastarem 8080, ne pa na njegovih naslednikih.
Ista zgodba se je ponovila žnj-krat in sedaj smo pri X86_64.


To pa pomeni:

-ob 64-bitnem coreu 8-bitne ( OSEM !!!) opcode s kupom prefixov. Ta fora je bila mogoče zanimiva na 8080, ki je imel rahitično 8-bitno vodilo, ne pa na modernem stroju s 64-128 bitnim vodilom na tistih efektivnih recimo 800MHz !

-Zanimivo je tudi to,d a zaradi tega novi stroji ne morejo biti združljivi s starimi. Na 80386 itd sli lahhko naklofal enega prefixa kolikor si hotel, pa je stvar delala. Na novih tega ne moreš. maksimalna dolžina ukaza z vsemi prefixi je 15 byteov.

- Zaradi tega so danes veliki problemi z dekodiranjem. kar je ukaz 8-biten in ima lahko kar nekaj prefiksov, je lahko v zajeti 64-bitni besedi kjerkoli. Vdelan dekoder mora dekodirat ukaz X, preden lahko zve, kje dejanjsko se začne naslednji ukaz.
Poleg tega mora biti samo dekodiranje speljano preko posebnih tabel z mikrokodov, kar pomeni shitload tranzistorjev in zakasnitve- latenco.

Zaradi kompleksnosti dekodiranja imajo današnji AMD64 čipi zmožnost dekodisrati samo do tri ukaze v eni 64-bitni besedi. Se pravi, ne glede na to, da so ukazi v osnovi lahko 8-bitni, od tega prednosti nimaš, samo glavobole.

Zaradi kojekakvih rakavih rasti imaš sedaj kupe ukazov, ki imajo več različnih opkod, pogosto z različno zakasnitvijo.

Zaradi ostankov 8-bitne preteklosti je CPU poln segmentnih registrov in šitloada dodatnih stvari, ki gredo zraven, tudi če jih ne vidiš.

FPU je bil katastrofalno izpeljan še v časih 8086, sedanja izvedba pa je AFAIK natančna kopija prvotne izvedbe, le da je on-chip.
Ta Forth-like princip je mogoče fajn, če je tvoj ALU abak z malo kroglicami, RAM pa blok papirja. Za nek moderen stroj je tole totalka bedno.

Še nisem videl stroj, ki bi sicer imel SIMD podaljšek, bi bil pa ta totalka ločen od FPU/ALU enote.
Še manjkrat sem videl stroj, kjer ti povedo,d a FPUja raje ne uporabljaj.

Enako je z veliko večino ukazov, ki so nekoč bili "tartaglavno tajno orožje". Imaš REP prefix, a bognedaj, da bi ga uporabil. Ravno tako loop pa še mnogo drugih ukazov.

IRG gate ? SYSGATE ? TASK GATE ? Ne me smejat. Namenjeno pa je temu ene bazilion strani.
GPIO - tole pa je komplikaža. Šitload ene elektronike ki ne dela v bistvu niča pametnega danes. PRaktično vse je že memory mapped.
So pa naredili znanost iz tega, ja. Feelin je ene tak, kot da bi moral pkositi manjšo trato s full dobro kosilnico, vendar bi moral pred košenjem poskenirati črtno kodo na vsaki bilki...

BTW: Si kje že videl pošten, nepederski 64-bitni CPU, ki nima ukaza za 64-bitni immediate operand ?

SSE1/2/3 etc je pa sploh zakon. Kup enih sorodnih mnemonikov, ki delajo različne stvari. In zaboga a ta stroj LoaDa in STora ali MOVa ? Naj se odloči že enkrat, kateremu taboru pripada.

V glavnem, stvar zgleda tako, kot bi jo zasnovali pri Monty Python.

Aja, CPUID. Imaš ukaz, s katerim lahko preveriš, kaj tvoj CPU ima in zna, a prej moraš preverit a ga sploh smeš uporabit... :))

To tkole na brzino in čez palec par stvari.




************


Odpri kdaj kak manual za Motorolo BTW:

Pardeset ukazov, 14 naslovnih načinov, 8 DATA in 8 ADDRESS registrov.

Feel free to combine ( more or less ).

Sladkati po okusu.
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

MrStein ::

Brezveze to pisat.

Tistim, ki vedo, samo odpiraš stare rane.
Kdor ne ve pa itak nič ne bo odnesel.
Teštiram če delaž - umlaut dela: ä ?

Bistri007 ::

Brane, meni se x86 ne zdi tako slab.

Tvoje kritike:
>Na 80386 itd sli lahhko naklofal enega prefixa kolikor si hotel, pa je stvar delala. Na novih tega ne moreš.
Ja, res zaradi optimizacij na kasnejši procesorji zaradi "pipeline" tehnologije ('486) niso podpirali več kot 16-bajtnih ukazov. Ampak v praksi jih ni nihče uporabljal, tako da to sploh ni omejitev. Pa daj sestavi en 16 bajten ukaz (s 386 ukazi) :)
Ena dodatna nekompatibilnost novejših procesorjev je samospeminjajoča koda par bajtov pred trenutnim CS:xIP. Treba je narediti far jump, če hočeš da CPU preveri, ali je bila koda spremenjena. Ampak to nikoli ni bilo na veliko uporabljano. Obstaja zanimiva zgodba okoli tega, kako je Intel skoraj kap, ko je videl, da je povzročil nekompatibilnost. Na koncu so ISVji poštimali, da samospreminjajoča koda naredi far jump, in je bil problem rešen.

Se pa strinjam, da so razširitve, kot so MMX, SSEx grdo zakodirane. Samo je Intel z novim AVXom ubral prav elegantno rešitev :) (LDS, LES)


Razširitve ?!?
Cela stvar je inicialni drek, ki je evoluiral tako, da je fasal raka in so razširitve v bistvu metastaze.
Bljak.

AVX je prav elegantno izpeljan. So pa res notri bolj ST, LD mnemonike, ampak...

-ob 64-bitnem coreu 8-bitne ( OSEM !!!) opcode s kupom prefixov. Ta fora je bila mogoče zanimiva na 8080, ki je imel rahitično 8-bitno vodilo, ne pa na modernem stroju s 64-128 bitnim vodilom na tistih efektivnih recimo 800MHz !
???
Osembitnih ukazov ni prav veliko. Ti večinoma delajo z *AX ali AL registrom. Ne razumem prav dobro te kritike.


>- Zaradi tega so danes veliki problemi z dekodiranjem. kar je ukaz 8-biten in ima lahko kar nekaj prefiksov, je lahko v zajeti 64-bitni besedi kjerkoli. Vdelan dekoder mora dekodirat ukaz X, preden lahko zve, kje dejanjsko se začne naslednji ukaz.
Poleg tega mora biti samo dekodiranje speljano preko posebnih tabel z mikrokodov, kar pomeni shitload tranzistorjev in zakasnitve- latenco.

To je bil problem pred par leti, sedaj zna procesor prav lepo razsekati x86 in podatke o mejah ukazov spraviti v kar velik code cache. Baje da danes ni performance penalies za variabilno dolžino ukazov.

Zaradi kompleksnosti dekodiranja imajo današnji AMD64 čipi zmožnost dekodirati samo do tri ukaze v eni 64-bitni besedi. Se pravi, ne glede na to, da so ukazi v osnovi lahko 8-bitni, od tega prednosti nimaš, samo glavobole.
???
A ti bi v 8 bajtov kode stlačil same enobajtne ukaze? Glede da je povprečna dolžina ukaza vsaj med 2-3 bajte, ni to neka huda omejitev.


>FPU je bil katastrofalno izpeljan še v časih 8086, sedanja izvedba pa je AFAIK natančna kopija prvotne izvedbe, le da je on-chip.
Ta Forth-like princip je mogoče fajn, če je tvoj ALU abak z malo kroglicami, RAM pa blok papirja. Za nek moderen stroj je tole totalka bedno.

Še nisem videl stroj, ki bi sicer imel SIMD podaljšek, bi bil pa ta totalka ločen od FPU/ALU enote.
Še manjkrat sem videl stroj, kjer ti povedo,d a FPUja raje ne uporabljaj.


FPU je stack based, kar je res bedno. Novi SSE ukazi so veliko boljši in ponujajo več zmogljivosti. Sicer res nimajo 80-bitne natančnosti, pa vseeno. Sicer pa x87 ni dostopen v 64-bitnem načinu, ne?


>Enako je z veliko večino ukazov, ki so nekoč bili "tartaglavno tajno orožje". Imaš REP prefix, a bognedaj, da bi ga uporabil. Ravno tako loop pa še mnogo drugih ukazov.
REP/REPE/REPZ/REPNE/REPNZ—Repeat String Operation Prefix. Zakaj tega ne bi uporabljal za kakšno iskanje stringa???

>IRG gate ? SYSGATE ? TASK GATE ? Ne me smejat. Namenjeno pa je temu ene bazilion strani.
GPIO - tole pa je komplikaža. Šitload ene elektronike ki ne dela v bistvu niča pametnega danes. PRaktično vse je že memory mapped.
So pa naredili znanost iz tega, ja. Feelin je ene tak, kot da bi moral pkositi manjšo trato s full dobro kosilnico, vendar bi moral pred košenjem poskenirati črtno kodo na vsaki bilki...

Ja, ti segmentni deskriptoji so bolj komplicirani. Sicer se danes uporablja segmente samo za sistemsko programiranje, aplikacije imajo s 32/64 bitnim naslavljanjem dostop do celotnega naslovnega prostora (včasih samo 64KB znotraj enega segmenta). Ampak ti segmenti določajo v katerem ringu (Privilege level, 0-3) se izvaja kaka koda oziroma so dostopni podatki.

>BTW: Si kje že videl pošten, nepederski 64-bitni CPU, ki nima ukaza za 64-bitni immediate operand ?
PowerPC :))
Kolikor vem, so tam vsi ukazi 32-bitni. RISC. Če želiš delati z 32 ali 64 biti, jih naložiš not preko pomnilnika. [lahko da se motim, je že nekaj časa odkar sem malo to zahec pogledal]

x64 ima ukaz za 64-bit immediate: REX.W + B8+ rd - ukaz MOV r64, imm64

Raje glej Intelovo dokumentacijo kot AMDjevo. Meni je dosti bolj pregledno napisana.
http://www.intel.com/products/processor...

Poglej si še AVX razširitve: http://software.intel.com/sites/avx/
Novih SSE ne bo. Novi Larrabee bo uporabljal nekaj podobnega AVX. AVX podpira 256-bitne operande.


>Aja, CPUID. Imaš ukaz, s katerim lahko preveriš, kaj tvoj CPU ima in zna, a prej moraš preverit a ga sploh smeš uporabit... :))
Če hočeš, da ti tvoj program ne bi zaštekal na kaki stari '486, potem pomaš s FLAGs preveriti, ali podpira CPU ukaz CPUID. Novejše 486, 100MHz DX4, izdane po Pentiumu, podpirajo CPUID.
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

Zgodovina sprememb…

  • spremenilo: Bistri007 ()

Brane2 ::

Ja, res zaradi optimizacij na kasnejši procesorji zaradi "pipeline" tehnologije ('486) niso podpirali več kot 16-bajtnih ukazov. Ampak v praksi jih ni nihče uporabljal, tako da to sploh ni omejitev. Pa daj sestavi en 16 bajten ukaz (s 386 ukazi) :)


Simpl. Katerikoli ukaz s ponovljenim prefixom.

As in :

LOOP: db P32 P32 P32 P32 P32 P32.... P32
ADC EBX,ECX
JNZ LOOP

Tole je bolj napamet, ni se mi dalo it gledat mnemonikov v buklo. Smisel zadeve- samospreminjajoča koda. Prefiksi pred tistim ADCjem ti igrajo vlogo NOPa, ki ne nastavi nobene zastavice in ne žre resursov. Recimo.


Ena dodatna nekompatibilnost novejših procesorjev je samospeminjajoča koda par bajtov pred trenutnim CS:xIP. Treba je narediti far jump, če hočeš da CPU preveri, ali je bila koda spremenjena. Ampak to nikoli ni bilo na veliko uporabljano. Obstaja zanimiva zgodba okoli tega, kako je Intel skoraj kap, ko je videl, da je povzročil nekompatibilnost. Na koncu so ISVji poštimali, da samospreminjajoča koda naredi far jump, in je bil problem rešen.


Očitno so to vmes poštimali. V AMD64 bukli piše, da selfchanging koda povzroči samo to, da je L1 instruction cacheline tega ukaza razglašen za neveljaven in tako ob prvem skoku tja CPU požre nakj taktov na to, da potegne vanj kopijo iz L1 datacachea...


Osembitnih ukazov ni prav veliko. Ti večinoma delajo z *AX ali AL registrom. Ne razumem prav dobro te kritike.


Njihovo število ni toliko važno kot njihova prisotnost. Čim ti imaš 8-bitne ukaze, to pomeni težke glavobole pri dekodiranju, saj dekoder nima bližnjic- instrukcija se lahko začne dobesedno kjerkoli. Tudi ko je našel začetni byte, CPU v splošnem ne more biti ziher, da bo na podlagi tega lahko vedel njeno dolžino, ampak se mora poukvarjati z naslednjimi bytei in to traja.
To je celo navedeno v bukli- če ni ravno treba, ne uporabljaj prefixov brezveze, npr REX.


To je bil problem pred par leti, sedaj zna procesor prav lepo razsekati x86 in podatke o mejah ukazov spraviti v kar velik code cache. Baje da danes ni performance penalies za variabilno dolžino ukazov.


Seveda so. To je celo navedeno v bukli. Če tega ne bi bilo, ne bi AMD te podatke hranil v L1 cacheu. Vsak cacheline ima dodatnih, user-invisible 72 bitov za ECC in predecoding.


A ti bi v 8 bajtov kode stlačil same enobajtne ukaze? Glede da je povprečna dolžina ukaza vsaj med 2-3 bajte, ni to neka huda omejitev.


1. Pa saj to pravim. Če je povprečen ukaz 16-24 biten, kje je prednost da se lahko začne na kateremkoli byteu ali wordeu ali celo še najraje DW ali QW ?
Kot opisano, so sami problemi s tem in nobene prednosti

2. Ni neverejtno,d a bi se kdo dejanjsko lahko potrudil in napisal handy, optimized loop, ki bi se izvedel superhitro.
Ne vidim zakaj ne. Pa od tega, kot rečeno, ne bi imel nič.


FPU je stack based, kar je res bedno. Novi SSE ukazi so veliko boljši in ponujajo več zmogljivosti. Sicer res nimajo 80-bitne natančnosti, pa vseeno. Sicer pa x87 ni dostopen v 64-bitnem načinu, ne?


Vsaj v AMD64 buklji nisem našel nič o tem, da ga dejanjsko ne bi mogel uporabljati. Le pod optimization guide piše, če ne rabiš 80-bitov full precision, "use SSEx instead"...


REP/REPE/REPZ/REPNE/REPNZ—Repeat String Operation Prefix. Zakaj tega ne bi uporabljal za kakšno iskanje stringa???


Jerbo je setup in overhead time večji kot pri ročnem Jxx. Piše v The Bukli. Ravno tako LOOP...
Nekje sem videl detajl o tem da je overhead odvisen tudi od vrednosti v CX registru. Je manjši, če je ta 8-bitna.
In umrl od smeha. Na školjki.



Ja, ti segmentni deskriptoji so bolj komplicirani. Sicer se danes uporablja segmente samo za sistemsko programiranje, aplikacije imajo s 32/64 bitnim naslavljanjem dostop do celotnega naslovnega prostora (včasih samo 64KB znotraj enega segmenta). Ampak ti segmenti določajo v katerem ringu (Privilege level, 0-3) se izvaja kaka koda oziroma so dostopni podatki.


Segmenti so taotalka neuporabni. Zveze s prioriteto itd pa imajo samo zaradi nevidnih extra bitov v segment descriptorju.
Tako so tudi uporabljeni v 64-bitnem modu. Vsi so neveljavni, razen proority bitov CS ( sam CS je vedno fiksiran na = oz se tako obnaša) in segmentov FS in GS.


PowerPC :))
Kolikor vem, so tam vsi ukazi 32-bitni. RISC. Če želiš delati z 32 ali 64 biti, jih naložiš not preko pomnilnika. [lahko da se motim, je že nekaj časa odkar sem malo to zahec pogledal]


O PowerPC nikoli nisem imel prav visoko mnenje. Nisem pa ziher da tega nima.


x64 ima ukaz za 64-bit immediate: REX.W + B8+ rd - ukaz MOV r64, imm64


Ja, MOV so nametastazirali gor. Se mi ni zdelo,d a se bo kdo obesil na to in nisem šel popravljat.
Drugega pa ni.


Poglej si še AVX razširitve: http://software.intel.com/sites/avx/
Novih SSE ne bo. Novi Larrabee bo uporabljal nekaj podobnega AVX. AVX podpira 256-bitne operande.


AVX je sicer fina stvar, ampak nekoristna, dokler ga dejanjsko nimam.


Če hočeš, da ti tvoj program ne bi zaštekal na kaki stari '486, potem pomaš s FLAGs preveriti, ali podpira CPU ukaz CPUID. Novejše 486, 100MHz DX4, izdane po Pentiumu, podpirajo CPUID.


Točno. Prej je bilo govora o tem nekje. "ZAkaj ne bi napisali svoj kernel v assemblerju s FASMom ?" In ker je to tip hotel za 386tko in ker je danes embedded 486 precej razširjen, je to dokaj smiselna zahteva.
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

Brane2 ::

BTW: Na AMD forumu me je preblisnila ideja in sem postavil vprašanje- zakaj se recimo Phenom ne dobi poleg x86 verzije tudi v kaki non-shitty izvedbi ?

Mislim, te zadeve omogočajo microcode update. In z njim rešujejo zelo širok spekter problemov.

Se ga ne bi dalo toliko razširiti, da bi lahko recimo zamenjal ISA ?

Saj če pogledaš zadeve, je vse že not. Instruction dekoderji so itak že navajeni težkega življenja in kak normalen ISA bi postavil pred njih kvečjemu lažje zahteve, kot dosedaj.

V glavnem, več na: http://forums.amd.com/forum/messageview...
On the journey of life, I chose the psycho path.

Bistri007 ::

Ja, res zaradi optimizacij na kasnejši procesorji zaradi "pipeline" tehnologije ('486) niso podpirali več kot 16-bajtnih ukazov. Ampak v praksi jih ni nihče uporabljal, tako da to sploh ni omejitev. Pa daj sestavi en 16 bajten ukaz (s 386 ukazi) :)


Simpl. Katerikoli ukaz s ponovljenim prefixom.

As in :

LOOP: db P32 P32 P32 P32 P32 P32.... P32
ADC EBX,ECX
JNZ LOOP

Joj, Brane. Seveda lahko namečeš prefixe enega za drugim, segmentne FS GS ES. Jaz sem imel v mislih en dolg ukaz z MOD R/M SIB, ki ga pljune ven compiler ali napiše programer, ki hoče napisati optimizirano kodo.


Očitno so to vmes poštimali. V AMD64 bukli piše, da selfchanging koda povzroči samo to, da je L1 instruction cacheline tega ukaza razglašen za neveljaven in tako ob prvem skoku tja CŠU požre nakj taktov na to, da potegne vanj kopijo iz L1 datacachea...

Ja, pa kaj mora biti narejen skok na nekaj bajtov naprej ročno v kodi? Če je tako, potem se ni nič spremenilo od časov 486. Na 386 je vse lepo delovalo brez kakršnega koli skoka v kodi.



To je bil problem pred par leti, sedaj zna procesor prav lepo razsekati x86 in podatke o mejah ukazov spraviti v kar velik code cache. Baje da danes ni performance penalies za variabilno dolžino ukazov.


Seveda so. To je celo navedeno v bukli. Če tega ne bi bilo, ne bi AMD te podatke hranil v L1 cacheu. Vsak cacheline ima dodatnih, user-invisible 72 bitov za ECC in predecoding.

8-)
Saj, ravno zaradi tega, ker ima podatke o začetku/koncu ukaza shranjene v hitrem L1 code cachu, ni "performance penalties".


1. Pa saj to pravim. Če je povprečen ukaz 16-24 biten, kje je prednost da se lahko začne na kateremkoli byteu ali wordeu ali celo še najraje DW ali QW ?
Kot opisano, so sami problemi s tem in nobene prednosti

Prednost za kodo je, če se začne procedura na 16byte ali 32byte aligned adresi - zaradi tega, ker je potrebno manj dostopov do RAMa, da naloži kodo.



REP/REPE/REPZ/REPNE/REPNZ—Repeat String Operation Prefix. Zakaj tega ne bi uporabljal za kakšno iskanje stringa???


Jerbo je setup in overhead time večji kot pri ročnem Jxx. Piše v The Bukli. Ravno tako LOOP...
Nekje sem videl detajl o tem da je overhead odvisen tudi od vrednosti v CX registru. Je manjši, če je ta 8-bitna.
In umrl od smeha. Na školjki.

Ja, tako ti je. Vsak procesor ima drugačen optimization guideline. Lepota x86 je, da napisana koda dela na vsak način. Če je pa res kritično potrebna hitrost, imaš pa posamezne odseke kode optimizirane za posamezne procesorje. Core2 izvede določen algoritem najhitreje če je "sfraziran" na en način, Athlon če je na drugega. Saj o tem se pogosto sliši...



PowerPC :))
Kolikor vem, so tam vsi ukazi 32-bitni. RISC. Če želiš delati z 32 ali 64 biti, jih naložiš not preko pomnilnika. [lahko da se motim, je že nekaj časa odkar sem malo to zahec pogledal]


O PowerPC nikoli nisem imel prav visoko mnenje. Nisem pa ziher da tega nima.

Če so vsi ukazi 4bajtni (32-bitni), kako boš not stlačil 32-bitni ali celo 64-bitni immediate???
Itanium IA64 je drugačen, ker ima 16bajtne ukaze (128bit)- not je plac za 32 in 64 bitni immediate.



x64 ima ukaz za 64-bit immediate: REX.W + B8+ rd - ukaz MOV r64, imm64


Ja, MOV so nametastazirali gor. Se mi ni zdelo,d a se bo kdo obesil na to in nisem šel popravljat.
Drugega pa ni.

OK, če je lahko PowerPC brez immediatov, potem lahko tudi v x64 zdržiš brez njih. Poleg tega je bolj optimalno uporabljati RAM. Sicer pa, kdaj bi ti dal 64-bitno fiksno cifro v kodo?

No, ne vem. Meni se zdi x86 "romantičen". Po eni strani sem vesel, da se še vedno uporablja, saj je to edini asembler, ki sem ga kdaj koli uporabljal. In ni za odmet, torej se je vrednost izvesticije v učenje x86 ohranila. Če bi danes vsi uporabljali IA64, bi bilo seveda drugače.

Ker bo Larrabee temeljil na x86, toliko bolje :)) X86 še na GPUjih!!!
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

Bistri007 ::

BTW: Na AMD forumu me je preblisnila ideja in sem postavil vprašanje- zakaj se recimo Phenom ne dobi poleg x86 verzije tudi v kaki non-shitty izvedbi ?

Mislim, te zadeve omogočajo microcode update. In z njim rešujejo zelo širok spekter problemov.

Se ga ne bi dalo toliko razširiti, da bi lahko recimo zamenjal ISA ?

Saj če pogledaš zadeve, je vse že not. Instruction dekoderji so itak že navajeni težkega življenja in kak normalen ISA bi postavil pred njih kvečjemu lažje zahteve, kot dosedaj.

V glavnem, več na: http://forums.amd.com/forum/messageview...


Za par procentov boljši performance se ti ne splača vreči stran kompatibilnosti. Ta performance pride tako ali tako z novo generacijo procesorjev. Edini problem, ki ga imata Intel & AMD z x86 arhitekturo, je hitro in optimalno prevajanje v mikrokodo. Kar pa je danes že skoraj rešen problem: če imaš tesne loope, je tako ali tako že vse v mikrokodi. Če imaš pa kodo, ki veliko skače naokoli - pa performance ni niti problem.

LONG LIVE X86.
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

Brane2 ::


Joj, Brane. Seveda lahko namečeš prefixe enega za drugim, segmentne FS GS ES. Jaz sem imel v mislih en dolg ukaz z MOD R/M SIB, ki ga pljune ven compiler ali napiše programer, ki hoče napisati optimizirano kodo.


Tisti prefixi imajo tam vlogo "lufta", va katerega lahko vstaviš po potrebi eno ali več instrukcij in/ali prefixov in sledi povsem spremeniš pomen.


Ja, pa kaj mora biti narejen skok na nekaj bajtov naprej ročno v kodi? Če je tako, potem se ni nič spremenilo od časov 486. Na 386 je vse lepo delovalo brez kakršnega koli skoka v kodi.


Mentalno sem se zatipkal. Ne skok ampak fetch. Ko je L1 cacheline invalidiran, ti pa poskusiš pognati instrukcij s te lokacije L1_I ugotovi,d a tega nima in zažene se L2 scan, vzporedno z njim pa poseben mehanizem preveri L1_D. Ker je updatean cacheline tam, je stvar relativno hitro uštimana.


Saj, ravno zaradi tega, ker ima podatke o začetku/koncu ukaza shranjene v hitrem L1 code cachu, ni "performance penalties".


Afaik so, čeprav manjši.


Prednost za kodo je, če se začne procedura na 16byte ali 32byte aligned adresi - zaradi tega, ker je potrebno manj dostopov do RAMa, da naloži kodo.


Pri današnjih mašinah je prednost predvsem v dekodiranju. Pri modernem DDR-1/2/3 RAMu plačaš prvi dostop do 8-16byteov, tistih X nalsednjih pa je veliko cenejših. Pa tudi pri kratkih opkodah je relativno manjša verjetnost, da boš ravno prečkal mejo 64-bitov, pa tudi če bi jo, boš tisto besedo verjetno rabil v kratkem. Razen če je šlo za skok naprej ali nazaj na nealignan ukaz, a to se da urediti SW, če gre za pogost skok.


Ja, tako ti je. Vsak procesor ima drugačen optimization guideline. Lepota x86 je, da napisana koda dela na vsak način. Če je pa res kritično potrebna hitrost, imaš pa posamezne odseke kode optimizirane za posamezne procesorje. Core2 izvede določen algoritem najhitreje če je "sfraziran" na en način, Athlon če je na drugega. Saj o tem se pogosto sliši...


Ne verjamem,d aje to slučaj tu. Prej gre za relikt iz preteklosti. Sicer so morali stvar omogočit zaradi rpeteklih generacij, ampak "doing it right" bi zahtevalo preveč resursov očitno... Tako so mnogi opcodei končali kot praktično neuporabne smeti.


Če so vsi ukazi 4bajtni (32-bitni), kako boš not stlačil 32-bitni ali celo 64-bitni immediate???
Itanium IA64 je drugačen, ker ima 16bajtne ukaze (128bit)- not je plac za 32 in 64 bitni immediate.


Govorim o opkodah. Jasno je,d a dodatni immediate operandi stanejo dodatne besede.


OK, če je lahko PowerPC brez immediatov, potem lahko tudi v x64 zdržiš brez njih. Poleg tega je bolj optimalno uporabljati RAM. Sicer pa, kdaj bi ti dal 64-bitno fiksno cifro v kodo?


PowerPC ima več registrov. Tam je manj frke. Pač naložiš immediate v en register in ta register uporabiš.


No, ne vem. Meni se zdi x86 "romantičen". Po eni strani sem vesel, da se še vedno uporablja, saj je to edini asembler, ki sem ga kdaj koli uporabljal. In ni za odmet, torej se je vrednost izvesticije v učenje x86 ohranila. Če bi danes vsi uporabljali IA64, bi bilo seveda drugače.


Romantičen ? Na MC68000 sem brez napora vedno imel v glavi vse mnemonike in vse posledice določenega ukaza. Mogoče bi me ujel pri zastavicah nekega MOVEa, ki ga nisem pogosto uporabil, pa verjetno še to ne.
Ko sem to rabil, sem ti lahko napisal opkodo vsakega ukaza napamet. Pa ne zato, ker bi bil genialec s fotografskim spominom, ampak zato, ker je bila stvar logična.

In ko sem enkrat vedel kako stvar dela, nisem rabil "1500 strani Optimization techniques & crap". Ko ti je jasno, kako stvar dela, tudi veš kako se "polaga v ovinke".

FPU je bil na zadevi dodan skozi protokol, ki je bil predviden od samega nastanka čipa, dolgo preden je folk videl prvi FPU.
Posledica je ta, da "čutiš" FPU kot bi bil del CPUja, pa če je na čipu ali posebej. Vsi registri so sicer FPU registri ampa dostop do njih je tak, kot ga pričakuješ.
Ravno tako je s katerokoli drugo napravo. Ti lahko dodaš SSEx,AVX in karkoli drugega brez problema na 68000, ker je bila za to predvidena.
Hell,folk je delal te zadeve v okvirih šolskih projektov.

Imaš polnofunkcionalno 68000tko, ki jo je tip naredil na FPGA za zabavo. Ker mu je Motorola nekaj sikala, je moral spremeniti ISA- v bistvu je samo invertiral "0" in "1" ke v opkodah.


Pa ne pravim, da je bila 68k povsem brez napak. A v primerjavi s temle crapom so bile nevidne.
In en pravim, da bi danes morali implementirati natanko to. Ampak nekaj v tem stilu (inteligenten, orthogonal, smart CISC) se zdi prekleto dobra ideja.

IMHO bi se nVidia morala povezati s Freescaleom in narediti odgovor na Larrabee v smislu PowerPC ali ColdFire (68k descendent) polja.
Če že ne bo IBM stopil na to polje s predelanim Cell-om v AM3 socketu na HT linkih, kar bi se IMHO znalo zgoditi.
On the journey of life, I chose the psycho path.

Brane2 ::

za par procentov boljši performance se ti ne splača vreči stran kompatibilnosti.


1. Performance v optimiziranih primerih ne bi bil samo za par procentov boljši. In ta izvedenka bi bila ravno za te primere.

2. Na nekem linux serverju mi x86 kompatibilnost pomeni natanko nič. Pač zakurblam gcc in prevedem kar rabim za svoj cpu.

3. Tisti procenti so še kako pomembni. Amd bi se ugrzinil za jajca, d a bi spravil ven phenoma 3ghz. Pa je prišel do 2. 6ghz.
Razlika med stelarnim uspehom in klavrnim začetkom: 26/30 ali manj kot 9%


Ta performance pride tako ali tako z novo generacijo procesorjev.


Ampak ti ga dobiš prej. K-10 je dober koncept in deneb je dober čip. Ampak za amd je ogromna razlika, če ti ga lahko dostavijo danes ali pa čez 6 mesecev...


Edini problem, ki ga imata intel & amd z x86 arhitekturo, je hitro in optimalno prevajanje v mikrokodo. Kar pa je danes že skoraj rešen problem: če imaš tesne loope, je tako ali tako že vse v mikrokodi. Če imaš pa kodo, ki veliko skače naokoli - pa performance ni niti problem.


Če bi bilo to čisto res, bi netburst bil kralj in folk sploh ne bi vedel za pipeline length...
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • polepsal: Brane2 ()

Brane2 ::

In BTW:

1. Sem na brzino preletel AVX. Same old, same old. Intel ne more iz svoje kože. Vedno poskuša biti kur*a vsem in njihov instruction set je "billion of special cases". Rabiš enciklopedijo in posebnega svetovalca med iskanjem in kombiniranjem ukazov.
Se jim pa pozna ameriška mentaliteta- ko ne gre več, uporabi večje kladivo/dodaj ekstra cilindre in široke gume/etc.

2. Kaj vidiš tako posebnega v x86 na grafikulji ? Katera od njegovih "prednosti" je tam pomembna ? Da lahko laufaš DOS in stare špile direkt na GPUju ?
On the journey of life, I chose the psycho path.

Brane2 ::

Aja, last, but not least:

mnemoniki v stilu "MOV TO , FROM" namesto "MOVE FROM , TO" in pa little endiannes resno rušita ustroj vesolja, kot si ga je bog zamislil in simetrijo Vesolja. je*eš, CERN-ov LHC, _tole_ bi moral prepovedat.>:D
On the journey of life, I chose the psycho path.

MrStein ::

Bisti007 se med vrsticami strinja, da je zanič, samo je čustveno navezan in vseeno govori "lepo".
Clear case, bi lahko rekli ;)
Teštiram če delaž - umlaut dela: ä ?
strani: 1 2 3 4 5


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Samsung predstavil prvi LCD monitor z DisplayPort vmesnikom

Oddelek: Novice / Zasloni / projektorji / ...
184073 (3053) opeter
»

Predavanji na temo superračunalnikov

Oddelek: Novice / Kiberpipa
52402 (1848) Matevžk
»

Četrt stoletja PC-ja

Oddelek: Novice / Procesorji
252826 (1470) opeter
»

Mozilla Thunderbird 1.5

Oddelek: Novice / Brskalniki
464916 (3156) krho
»

Wikipedia uvedla novo zaščito pred vandalizmom

Oddelek: Novice / Varnost
435597 (4054) Dragi

Več podobnih tem