Windhund, K9, Was sagt der Teesatz? Wer petzt?

[BlackBirdSR]

Original geschrieben von greyhound
Wie sieht es denn mit Speichern auf Basis neuer Materialien aus. Stichwort ferromagnetisch.
Könnte das nicht der Nachfolger in sagen wir mal 2-3 Jahren sein ?

sehr unwahrscheinlich
5+ mindestens würde ich mal sagen.
'

 

[[DUF2]Vinzenz]

nana leute...
lasst erst mal DDR2 kommen, auf dem nvidia themenabend hab ich gehört, dass das ziemlich schwierig sei auf grafikkarten (weshalb die FX 5900 auch mit DDR1 kommt), und erst recht als hauptspeicher.
was die prozessoren angeht, 2GHZ sind doch erst der anfang... mit SOI kann AMD weiteraus höhere taktfrequenzen erreichen un 64bit wird - auf lang oda auf kurz - kommen und wenn die plattform schon da ist AMD64, dann wird es auch die entsprechende software dafür geben.
warum intel definitiv vor 2005 noch keine 64bit CPUs rausbringen will, kann ich net sagen. klingt irgendwie bekloppt, wenn 64bit mit dem athlon 64 sogar für normal anwender verfügbar ist... ohne dass 32bit applikationen ausgeschlossen werden!

P.S. weiss irgendjemand ob der opteron/athlon 64 im kompatiblitätsmodus 32- und 64bit anwendungen gleichzeitig ausführen kann?

cu Vinzenz

 

[greyhound]

Intel setzt auch kein SOI ein, wodurch sie jetzt wahrscheinlich Probleme bekommen. Was mich nachdenklich macht ist die Tatsache das Intel es nach dem Debakel mit dem P3 der die 1ghz nicht erreichte, geschaft haben den P4 auf reichlich 3Ghz aufzubohren. Das ist bei aller Kritik am P4 schon eine reife Leistung schließlich spielt nicht nur das design der CPU eine Rolle... Ich denke das Intel isch für 64 bit und SOI schon etwas einfallen lassen wird.

Zitat:

"Legacy Mode:
Im Legacy-Mode verhält sich der Mikroprozessor wie ein reiner 32 Bit Mikroprozessor. Das Betriebssystem sowie alle auszuführenden Programme müssen im 32 Bit Maschinencode vorliegen. Der Mikroprozessor verfügt über die Standard x86-Register (32 Bit), sowie die MMX, SSE und 3DNow Register (128 Bit). Die FPU-Register sind wie im Long Mode 80 Bit lang, der Befehlszähler 32 Bit.

Long Mode:
Der Long-Mode ist die Besonderheit am Hammer. Hierbei verhält sich der Mikroprozessor wie ein 64 Bit Mikroprozessor. Das Betriebssystem muss für diesen Betriebsmodus im 64 Bit Maschinencode vorliegen, da der Virtuelle Adressraum mit 64 Bit adressiert wird.

Dem Programmierer stehen acht zusätzliche GPRs zur Verfügung, mit jeweils 64 Bit Länge. Ebenso sind alle weiteren General Purpose Register 64 Bit lang. Ein partieller Zugriff auf die Register ist weiterhin möglich, über EAX werden die untersten 32 Bit des RAX-Registers adressiert, über AX die untersten 16 Bit, über AH und AL die jeweils untersten 8 Bit.


Das besondere am Long Mode ist die Aufspaltung zwischen reinem 64 Bit Mode und dem Compatibility Mode. In diesem Modus führt der Mikroprozessor bei installiertem 64 Bit Betriebssystem weiterhin 32/16 Bit Maschinencode aus. Vom Standpunkt der Anwendung ist zwischen 32 Bit Legacy Mode und 32 Bit Compatibility Mode nicht zu unterscheiden.
Die 32 Bit langen Operanden und Befehle werden mit Nullen auf 64 Bit Länge verlängert, so dass beispielsweise aus dem 32 Bit Wert 4F8C(Hex) der 64 Bit Wert 00004F8C(Hex) wird. Ein Zugriff auf die zusätzlichen Register R8-R15 sowie XMM8-XMM15 ist im Compatibility Mode nicht möglich. "
D'Espice

Ich hoffe damit sind alle Klarheiten beseitigt

Den kompletten Artikel von D'Espice findest Du unter :
http://www.planet3dnow.de/artikel/diverses/64bitpreview/index.shtml

 

[BLJ]

wie wärs mal mit SMP on DIE + Kompatible Taktrate statt immer schnellerer CPU's ?

SMP on DIE wär zwar wohl auch teurer, da weniger geeignete DIE's pro Wafer anfallen würden (Vermutung), genau so wie die Ausbeute an schnellen CPU's geringer ist.

Auch normales, verbreitet SMP wär ja supa.

Aba kann mir jemand mal den Unterschied zwischen SMP und Hypertreading Softwaremässig erklären? (HW mässig weiss ich schon..)

Müsste Hyperthreading unterstützdene SW nicht auch SMP unterstützen?

thx
cu

 

[Bokill]

aus dem Geode- Thread "Steigt AMD in Vermarktung von Thin Clients und Set-Top-Boxen ein?"
http://www.planet3dnow.de/vbulletin/showthread.php3?threadid=112032&highlight=Geode

Antwort?
Beim dritten überfliegen ist mir etwas ins Auge gestochen!
Dies könnte der Grund sein, eventuell etwas nettes für den Windhund?!

quote:
--------------------------------------------------------------------------------

*< 1W typical power dissipation

* Optimized Unifed Memory Architecture (UMA) with patented compression technology

--------------------------------------------------------------------------------
Fette Speicherbandbreite mit Kompression?!

Is aber halt ganz wilde Spekulation!
Klingt halt ganz nett, zusammen mit L0- Cache und SMT und SMP

 

[mtb][sledgehammer]

Original geschrieben von BLJ
wie wärs mal mit SMP on DIE + Kompatible Taktrate statt immer schnellerer CPU's ?

SMP on DIE wär zwar wohl auch teurer, da weniger geeignete DIE's pro Wafer anfallen würden (Vermutung), genau so wie die Ausbeute an schnellen CPU's geringer ist.

Auch normales, verbreitet SMP wär ja supa.

Aba kann mir jemand mal den Unterschied zwischen SMP und Hypertreading Softwaremässig erklären? (HW mässig weiss ich schon..)

Müsste Hyperthreading unterstützdene SW nicht auch SMP unterstützen?

thx
cu

SMP und SMT (zu dem Hyper Threading gehört) bringt nur dann etwas, wenn die Software als Multi Threaded Software geschrieben ist. Hat die Software nur einen Thread, bringt beides nichts. Bei SMP liegt die eine CPU komplett brach, bei HT nutzt eben der eine Thread die komplette Rechenleistung. Da die meiste Software (im Consumer Sektor) eben nicht multithreaded ist, wäre der zweite Prozessor bei SMP einfach zu teuer, SMT ist aber ziemlich günstig zu implementieren.

Man kann aber IMO keine Software nur auf SMT optimieren. Denn sobald sie Multithreaded ist (Voraussetzung für HT Vorteile) profitiert davon auch SMP.

 

[Bokill]

Anregung.
"Wie werden sich die CPUs die nächsten 2Jahre weiterentwickeln?"
http://www.planet3dnow.de/vbulletin/showthread.php3?s=&postid=886042#post886042

 

[Bokill]

...AMD originally envisioned a RISC-like FP model for Hammer called TFP but wisely decided it was easier and safer to ride Intel’s slipstream instead...

http://www.realworldtech.com/page.cfm?ArticleID=RWT012603224711&p=4

Netter Artikel!

Da kam mir der Gedanke woran besonders am Hammernachfolger gefeilt werden kann, Leistungsmässig ist der Opteron ja in die klassische Phalanx der bisherigen 64Bit CPUs durchgebrochen.
Vergleichsweise schwach ist dort nur die FPU- Einheit, der Hammer hat hier ja auch noch die wenigene Register aus der X-86 Zeit!

 

[Bokill]

Der verlinkte Artikel ist schon Steinalt, damals war der K8 ebenso geheimnisvoll wie der jetzige Windhund K9.

Damals waren die vorhergesagten Goodies 64Bit und die neue FP- Einheit.

Wie wir nun wissen hat AMD das Projektr an allen Ecken und Enden beschleunigt und sich für die 64Bit als wichtigste Einheit entschieden.


1. Welchen Markt könnte der K9 Ansteuern?

Ganz Einfach, den Server und Workstation Markt bzw noch fettere Maschinen.


2. Was ist denn vergleichsweise schwach, gegenüber den Alphas (die in 5 jahren dann wirklich Alteisen sind)?

Die FP- einheit!


3. Warum wird die FP- Einheit meiner Meinung nach nicht verdrängt durch SSE?

Wissenschaftliche Programme mit hoher Genauigkeit!


4. Und noch ein weiteres Argument für TFP, AMD ist sicherlich bedacht so viel Wissen wie möglich aus eigenen Quellen zu nutzen, sicherlich wurden schon viele Mittel in TFP investiert, wäre doch schade um die Mittel oder?

5. Bestärkt wird meine These vor allem mit den alten FP Registerstand, wie sie auch im Athlon und Vorgängern steckt, dies schreit doch nach Erweiterung!

aber nun zum superalten Artikel:
"AMD's 64 Bit Gamble
Dr. Jekyll and Mr. RISC"

...If AMD decided to implement a bilingual x86/RISC design for the K8, an important decision is whether to design yet another new RISC architecture or license an existing one. AMD has shown in the past that it is self-confident enough not to feel the need to reinvent the wheel, so the odds are they would license an existing RISC ISA. The choice of the Alpha ISA seems obvious, as AMD has previously licensed Alpha intellectual property (IP) from Compaq in the form of bus technology for the K7/Athlon family. The Alpha is also a particularly clean and streamlined RISC ISA free of annoyances, such as delayed branches and redundant instructions, from being extended from 32 to 64 bits. As such, it would likely be the first choice by AMD’s architects and designers (many of whom are ex-Alpha designers).

However, there are at least three other explanations for the 6,081,884 patent which do not involve a full blown bilingual x86/RISC K8 design. The first is that the RISC instructions and functional units shown in Figure 1 are strictly the 'RISC-like' TFP floating point extensions to x86-64 previously mentioned, and all integer and memory access instructions are performed by the two x86/RISC units. A strong argument against this hypothesis is the fact that Figure 1 would imply an unusually wide capacity for issuing floating point instructions - from 60 to 100% of issue capacity. In contrast the Alpha 21264, a processor designed to perform well for FP intensive applications, can issue four integer instructions and two FP instructions per clock cycle. This would suggest the RISC units include integer processing capabilities.

The second explanation is that the RISC instructions shown in Figure 1 actually represent micro-ops (uops), and that the predecoder block actually decomposes some x86 instructions into uops. In this case, the K8 instruction cache would store a mixture of micro and macro (x86) operations. This would be a sort of hybrid scheme between the Willamette trace cache, which only stores uops, and existing x86 processors, like the P6 and K7. The third explanation is that the patent covers work that either AMD abandoned (supposedly the K8 project was scaled back to be a more of an evolution of the K7 core), or simply wrote up as a defensive patent against IA-64 to place a stake in the ground for freedom of action for the future (K9?).

http://www.realworldtech.com/page.cfm?ArticleID=RWT071800000000&p=5

und die nächste Seite "Conclusion"

...For most users, the K8’s TFP RISC-like FP extension may be of much more interest since it should provide eventual benefit for users of high performance 3D graphics applications, such as games. What K8’s 64-bitness and TFP provides to AMD is the means for it to counteract the huge advertising campaign that will accompany Intel’s push to move its customer base from X86 to IA-64, which will likely start in earnest in about two or three years. Finally, the recent intriguing patent disclosure by AMD also suggests that we cannot discount the possibility of a big surprise when K8 is introduced.

http://www.realworldtech.com/page.cfm?ArticleID=RWT071800000000&p=6

Natürlich ist der Artikel hoffnungslos veraltet und AMD ist natürlich bereit das Rad neu zu erfinden, bzw nimmt gerne Teile vom K7, es ist halt strategisch wichtig unabhängig zu sein. Aber sie sind ebenso bedacht rationell jeden Transistor zu nutzen, jeder mm² zählt!

PS. THX Blackbird SR

 

[Bokill]

Hier ein kleiner Auszug zu den derzeitigen Entwicklungen der Speichermodule,
ich denke da wird AMD noch ziemlich viel Zeit aufwenden für die "richtige" Speichertechnologie.
Meiner Meinung nach wird der K9 ebenso einen Speichercontroller haben wie der Hammer, jedoch muss AMD jetzt schon Schwerpunkte zur Nächsten CPU- Generation setzten?! Eine extrem schwierige Phase!

Memory Market Overview: August 2003 (page 3)

Winding up the highlife part, I’d like to add a few words about a hero of the days long gone – Rambus. If you think that it’s again about legal actions, you are wrong. The company is just being “reanimated”. Quite naturally, this task fell to the hands of the Japanese that are the leading RDRAM manufacturers now. Toshiba and Elpida in collaboration with Rambus announced new memory architecture – XDR DRAM. It is based on the high-speed data-transfer interface Yellowstone, Rambus announced quite a while ago. They promise clock-rates of 3.2-6.4GHz and higher with an up to 100GB/s bandwidth. That’s not going to be very fast, though: samples in the next year with mass production (if there’s any demand) in 2005

Bildlink XDR Systemtopologie:
http://www.xbitlabs.com/images/memory/mem-aug2003/mem0703.jpg

It’s characteristic that another Rambus fan, the Korea-based Samsung licensed Yellowstone in July. And this fact makes it all the more serious – see the world top five above. However, Samsung claims it is going to use Yellowstone to its main purpose: as a data-transfer interface in household appliances, as well as graphics and communication equipment. On the other hand, they may mean exactly XDR – seems like no one has ever positioned it as a purely PC memory type...

Well, that’s about all the last July was notable for. As for niche markets, the news is the success of Ramtron’s FRAM – Promise is going to use 256Kb chips in its RAID controllers for storing operation-critical data. Matsushita also announced its intention to sample SOC chips with the ability to integrate into them necessary FRAM amounts. In case you forgot, Ferromagnetic Random Access Memory combines the advantages of both flash memory (nonvolatile) and DRAM/SRAM (low latencies, and fast overall operation). This memory type has been developed by numerous companies for a few years already. So, the fact that it’s now ready for the market is really nice – this memory has a bright future ahead.

http://www.xbitlabs.com/articles/memory/display/mem-aug2003_3.html

 

[HenryWince]

> Wird der Windhund, K9 ebenso weiter auf der Entwicklungslinie des K7 liegen?

Jup, denke ich schon.

> Welche Trends sind denn zur Zeit besonders aktuell?

Integrierte Memory Controller, Monster Caches, SMT, MultiCore Chips (Gemini, Power5, Montecito), TOE, LowPower

> Was machen denn die anderen CPU- Schmieden?

Genau das

> Wird mit dem Windhund endlich einiger Ballast abgeworfen? (A20 Gate)

Nope,glaub ich net: AMD64 = evolution not revolution.

> Ist DOS immer noch wichtig zum Initiieren vom BIOS?

Du meinst wohl eher umgekehrt? Ja, das BIOS wird nach wie vor den gesamten Legacy-Muell mitschleppen. Sei es die Traps für die unsupported 286 opcodes oder auch die int's die DOS benoetigt.

> Reicht die Tauglichkeit von 32Bit und 64Bit- Programmen?

Was meinst du damit?

>Hat AMD immer noch einen SSE- Intelclone oder erweitert AMD ausgehend von SSE2 selber die Einheit, um aus der Abhängigkeit von Intel zu geraten?

Welcher Abhängigkeit? Es gibt ein Cross-Licensing Abkommen zwischen AMD und Intel, das es AMD erlaunbt SSE2 selber zu implementieren. Im Gegenzug darf Intel x86-64 implementieren (was Intel-Intern wohl Yamhill heisst). Funktional könnte ich mir Vorstellen, dass 128 bit Floats unterstützt werden (sowas wie X_Floats bei den Alphas).

> Hat der Yamhill Relevanz, wie antwortet AMD darauf?

Das ist genau Umgekehrt. Intel antwortet mit Yamhill auf AMD. Wenn das passiet hat AMD schon viel gewonnen. Dann gebe ich dem Itanium kaum eine Chance mehr.

> Wieviel Mio/Mrd Transistoren sind zu erwarten bei einer klassischen Diegrösse von 100mm² - 180mm²

Kommt auf die Technologie an und die Verteilung Logik/Cache. Die Größenordungen wurden schon genannt. Im vergleich zu den Itanics ist das aber noch klein Man munkelt hier was von fast 500mm^2 Die-Size.

Andere Spekulationen zum K9:
- Ein paar extra Cache-Tiles um den Yield zu erhoehen (macht Intel beim 9MB Madison)
- TCP Offloading Engine im Core (ist zwar weit hergeholt, aber bis dahin könnte das wohl eine Notwendigkeit sein)

Wesentlichen Einfluss auf den K9 wird die weitere Entwicklung im Speichermarkt sein. Es ist abzusehen das die Bandbreiten höher werden, fragt sich nur wie gut die Ingenieure sind um die nach wie vor hohe Latenz zu verstecken. Ich denke es wird früher oder später auf Message-Basierte auf Point-to-Point Interfaces mit wenigen Pins hinaus laufen -- Sowas wie HT2 zum Memory -- so um 2010.

 

[Bokill]

Du hast ein Fan gewonnen, für deine Beiträge HenryWince, der Titel Cadet sollte bei dir zumindest noch mit goldener Spange und Schwertern ergänzt werden.

> Ist DOS immer noch wichtig zum Initiieren vom BIOS?

Du meinst wohl eher umgekehrt? Ja, das BIOS wird nach wie vor den gesamten Legacy-Muell mitschleppen. Sei es die Traps für die unsupported 286 opcodes oder auch die int's die DOS benoetigt

Genau diesen Legacy- Müll meinte ich, ich denke dass AMD Kompatibelität heilig ist, aucj für den Hammernachfolger.
Aber ich wollte halt sehr weit in die Zukunft spinnen.

> Reicht die Tauglichkeit von 32Bit und 64Bit- Programmen?

Was meinst du damit?

Zugegeben etwas knapp formuliert. Ich wollte hier ebenso weiter spinnen, ist es denklbar, dass der K9 vollständig die 32Bit- Pfade verlässt? Aber ich denke dass Karma der totalen Kompatibelität spricht dagegen.
Rein theoretisch wäre es für das Entwerfen des Nachfolgers hübscher und leistungsfähiger, wenn der alte Ballast komplett von Bord geworfen wird. (Initiative: Rettet das A20- Gate )

>Hat AMD immer noch einen SSE- Intelclone oder erweitert AMD ausgehend von SSE2 selber die Einheit, um aus der Abhängigkeit von Intel zu geraten?

Welcher Abhängigkeit? Es gibt ein Cross-Licensing Abkommen zwischen AMD und Intel, das es AMD erlaunbt SSE2 selber zu implementieren. Im Gegenzug darf Intel x86-64 implementieren (was Intel-Intern wohl Yamhill heisst). Funktional könnte ich mir Vorstellen, dass 128 bit Floats unterstützt werden (sowas wie X_Floats bei den Alphas).

Intel wird mit SSE immer einen halben Schritt voraus sein, einfach dadurch, dass Intel einen eigenen Standard erfindet, so wird AMD auf der vergifteten Schleimspur von Intel wandeln, nich gerade leistungsfördend, auch unter PR- Gesichtspunkten eine zweischneidige Klinge. Mit TFP oder ähnlichem gestaltete AMD einen eigenen Pfad, allerdings dann mit aufgegebener Kompatibelität zum vergifteten Intelpfad.

> Hat der Yamhill Relevanz, wie antwortet AMD darauf?

Das ist genau Umgekehrt. Intel antwortet mit Yamhill auf AMD. Wenn das passiet hat AMD schon viel gewonnen. Dann gebe ich dem Itanium kaum eine Chance mehr.

Die Antwort Yamhill setze ich schon als gegeben an, daher die Frage wie AMD wiederumm auf den Yamhill antwortet. Is halt ein wilder Spekulationsthread, der Yamhill wird ja von Hans de Vries schon im Prescott und Nachfolger vermutet, is halt nur nicht freigeschaltet, wie damals HT im P4.
Sicher ist, dass AMD schon irgendwie auf den Yamhill antworten muss, wenn Home64Bit sich schnell verbreitet.

Ansonsten stimme ich deiner Meinung zu 110% bei.

Wesentlichen Einfluss auf den K9 wird die weitere Entwicklung im Speichermarkt sein. Es ist abzusehen das die Bandbreiten höher werden, fragt sich nur wie gut die Ingenieure sind um die nach wie vor hohe Latenz zu verstecken. Ich denke es wird früher oder später auf Message-Basierte auf Point-to-Point Interfaces mit wenigen Pins hinaus laufen -- Sowas wie HT2 zum Memory -- so um 2010.

Besser kann mans kaum noch schreiben

 

[Bokill]

Heise hat wirklich eine nette Suchmaschine.
Zum Stichwort EPIC wurden nette Artikel herausgegeben.

1. Hartmut Gieselmann (hag)
Grafik-Bombe
Spiele, 3D-Shooter, Unreal Tournament 2003, Action Shooter, Infogrames, Epic Games, Digital Extremes
c't 23/02, Seite 225

2. Andreas Stiller (as)
Body-Check
Voruntersuchung von Itanium 2 und Opteron
Report, Prozessoren, Opteron, Sledfgehammer, Clawhammer,Itanium, Merced, McKinley, x86-64,Core, Pipeline,Caches, XBAR, HyperTransport, IA-64, EPIC, Bündel, SSE, SSE2,RSE,DDR333, SPEC, Gretchenfrage, Montecito
c't 13/02, Seite 104

3. Andreas Stiller (as)
Prozessorgeflüster
Von Cowboys und Indianern
aktuell, Prozessoren, Steve Ballmer, Craig Barret, Scott McNealy, Brookdale, Arapahoe, HyperTransport, PCI-SIG, Intergraph, Patentverletzung, IA-64, PIC, EPIC, UltraSparc III, UltraSparc V, Texas Instruments, ARMv6
c't 17/01, Seite 16

4. Andreas Stiller, Peter Siering (as)
Architektur für 'echte' Programmierer
IA64, EPIC und Itanium
Report, Prozessoren, Itanium, Merced, Bundle, Triplett, virtueller Adressraum, physischer Adressraum, TLB, Page-Table, Register Stack Engine (RSE), Register Rotation, Software Pipeline,Loop Unrolling, FDIV, SIMD,Predication,IA32-Emulator,Pipeline
c't 13/01, Seite 148

5. Andreas Stiller (as)
64 Bit zum Üben
Intel stellt Itanium-Prozessor offiziell vor
aktuell, Prozessoren , Itanium, EPIC, HP, PA-Risc, McKinley, UltraSparc, SPECint2000, SPECfp2000, Linpack, TPC-C,
c't 12/01, Seite 18

6. Andreas Stiller (as)
Titanomachie
Microprocessor Forum 1999
aktuell, Prozessoren , Merced, Itanium, EPIC, Power4, Alpha EV8, G4+, Fujitsu SPARC64 V, Sun MAJC 5200, SMT, ILP, DDR-SDRAM
c't 22/99, Seite 16

7. Andreas Stiller (as)
Prozessorgeflüster
Intels Weg zu 64 Bit
aktuell, Prozessoren, IA64, EPIC, Merced, MMX,ISSE
c't 12/99, Seite 28

8. Andreas Stiller, Dr. Sabine Cianciolo (gs)
Schleier um 'Merced' ein wenig gelüftet
Intels 64Bitter und die anderen x86er auf dem Microprozessor Forum
aktuell, Merced, HP, EPIC, AMD, Cyrix, VLIW
c't 12/97, Seite 44

9. Dr. Heinz Werntges (ae)
Von Rahmen und Bildern
Grafikimport in TeX/LaTeX
Know-how, TeX/LaTex-Grafikintegration, Textverarbeitung, Metafont, PiCTeX, Postscript, TeXcad, rumgraph, Xfig, emTeX, bm2font, hp2xx, epic.sty
c't 12/92, Seite 252

http://www.heise.de/ct/inhverz/search.shtml?T=EPIC&Suchen=suchen

Besonders nett in diesem Zusammenhang erscheinen mir zwei Artikel:

Andreas Stiller
Prozessorgeflüster
Intels Weg zu 64 Bit
Nun ist sie endgültig, Intels 64-Bit-Architektur IA64. Gemeinsam mit HP hat Intel die Spezifikation V1.0 veröffentlicht, deren erste Hardware-Inkarnation der Merced Mitte 2000 sein wird.

Es ist schon beeindruckend, was auf knapp 800 Seiten Dokumentation (IA64 Application Instruction Set Architecture Guide und Developer´s Architecture Guide [1]) alles zu finden ist. Kein Wunder, ist doch die Architektur komplett neu und bietet Gewaltiges: Jeweils 128 64-Bit-Register für `General-Purpose´ und Gleitkomma harren ihrer Programmierung, dazu kommen diverse applikationsspezifische Register sowie sogenannte Predication- und Branch-Register.

Vorbei sind die Zeiten, wo man sich mühsam mit popeligen 8 FPU-Registern abplagen mußte, die zu allem Überfluß auch noch als Stack organisiert waren.

IA64 hat nun wie der PowerPC eine volle 3-Adreß-FPU, nur halt einen viermal größeren Registersatz. Zum Vergleich: Alpha 21264 verfügt über 80 Integer und 72 FP-Register. Auch die Integer-Operationen sind `3-adressig´, das heißt: eine Operation verknüpft zwei beliebige Register und schreibt das Ergebnis in ein drittes, wobei sich die IA64-Assembler-Syntax praktischerweise an Hochsprachen anlehnt, also statt

op R1,R2,R3
op R3 = R1,R2

Hinzugekommen sind ferner Erweiterungen der nach IEEE normierten Gleitkomma-Befehle. So kennt IA64 nun auch Multiply-ADD, Minimum und Maximum, vierfache Genauigkeit sowie spekulative Registerwerte.

Alle IA64-Befehle belegen RISC-artig eine konstante Länge von 41 Bit. Befehle mit 64-Bit-Konstanten (Immediates) benötigen zweimal 41 Bit. Jeweils drei Befehle befinden sich zusammen mit 5 Control-Bits (Templates) in einem 128-Bit-`Bündel´ (Bundle), jeder Befehl in seinem 41-Bit-`Slot´. Die Templates legen fest, ob und welche Befehle parallel ausgeführt werden können und ob das nächste Bundle ebenfalls noch parallel ausführbare Befehle enthält. Es ist Aufgabe des Compilers, die Befehle optimal zusammenzustellen und die Templates korrekt zu besetzen: Der Prozessor selbst achtet nicht mehr auf irgendwelche möglicherweise komplizierten Abhängigkeiten der Befehle und Daten untereinander, sondern führt nur noch blind - und schnell - aus. Diese Methode hat Intel EPIC (Explicitly Parallel Instruction Computing) getauft.

Durch die Bundle-Verlinkung ist EPIC unabhängig von der realen Hardware. Merced wird vermutlich zwei Bundles (sechs Befehle) parallel ausführen können, spätere Prozessoren auch mehr...

http://www.heise.de/ct/99/12/028/default.shtml
[/quote]
Daher EPIC, und meine Spekulationen zum K9 mit einer wirklich starken FPU- Einheit vom K9

Der zweite Artikel ist auch nicht wirklich Taufrisch...
http://www.heise.de/ct/99/22/016/default.shtml

c't 22/99, S. 16: Prozessoren
Andreas Stiller

Titanomachie
Microprocessor Forum 1999
Das diesjährige Treffen der Prozessor-Gurus im sonnigen San Jose verlief ganz unter dem Motto: Zeig mir deinen 64-Bitter, dann zeig ich dir meinen. Der Bogen spannte sich von konkreten, bereits als Prototyp vorliegenden Designs wie Merced bis hin zu noch recht akademischen Monster-Chips mit einer Viertelmilliarde Transistoren für das Jahr 2004 (Alpha EV8).

...

Conan mit dem Hammer
Die größte Spannung unter den 64-Bittern wusste jedoch AMDs K8-Prozessor zu erregen. Bei dem unter dem Codenamen Sledgehammer (Vorschlaghammer) entwickelten Design erwartete man weniger einen 64-Bit-Boliden mit völlig neuem Aufbau à la Itanium als vielmehr eine geschickte Erweiterung des vorhandenen Athlon-Designs. Und in der Tat, wie weiland 1985 beim Übergang von 16 auf 32 Bit hat AMD in dem x86-64 genannten Instruction Set einfach ein 64-Bit-Segment (nur flat, ohne Segmentregister) hinzugefügt, die Register auf 64 Bit erweitert, ein paar Konvertierbefehle und Präfixe zugefügt - das wars nahezu schon: 64 Bit also mit minimalem Aufwand, optimaler Kompatibilität zu 32 Bit und hoher Code-Dichte. Nur fünf Prozent mehr Platz auf dem Die erfordert diese konservative Herangehensweise, die aber im Unterschied zu Itanium auch den alten 32-Bit-Code mit maximaler Performance beschenkt.

Bei der FPU allerdings wurde AMD etwas mutiger. Zwar unterstützt sie logischerweise die klassischen FPU/MMX/3Dnow!-Modi, darüber hinaus hat AMD aber den Stack-Engpass mit einem neuen Modus gesprengt. Die FPU arbeitet dann als volle Drei-Adressmaschine mit einem Registersatz von ‘deutlich mehr’ als 8 Registern (vermutlich wohl 32).

Fraglich ist natürlich, welche Betriebssysteme x86-64 unterstützen werden. Wie es heißt, sei AMD aber in intensiven Gesprächen mit Microsoft. Ein wenig Zeit kann man sich dafür wohl noch lassen, denn Termine für Sledgehammer gab AMD nicht offiziell bekannt, es wird wohl frühestens 2001 werden. Dafür will man im nächsten Jahr die Athlon-Familie weiter ausbauen. Für Workstations und Server sollen dann 1-MByte- und 2-MByte-L2-Caches mit ‘Full Speed’ sowie 266 MHz FSB verfügbar sein (Double Data Rate, mit 133 MHz x 2). Daneben schlägt AMD ein neues I/O-Buskonzept namens LDT vor (Lightning Data Transport), das skalierbar zwischen den System-Controllern (Northbridges) und der Peripherie mit Datenraten von 1,6 GBit/s pro Pin agieren soll. Bei einer 16/16-Verbindung sind so 6,4 GByte/s in beiden Richtungen möglich. Gedacht ist LDT vor allem für die Verknüpfung in Multiprozessorsystemen...

Tja das mit der FPU- Einheit wurde zugunsten von SSE ja gekippt, da wurde starker Rum (TFP) gegen bekömmlichen "Hustensaft" (SSE) eingetauscht.

 

[Ostsee]

Original geschrieben von intel_hasser
@SteveBarerra

Das ist einfach falsch, heutige CPUs sind praktisch überhauptnet mit dem 8086 verwand.

Also der 8086 ist ein völlig anderer Schuh, und kein heutiges 32bit Betriebssystem würde auf einem 8086 laufen, weil da schon der 32bit Modus einfach komplett fehlt (der 8086 ist nunmal ein 16bit Prozzi).

Das wiederrum stimmt so auch nicht. Wenn es allein um die Grundstruktur geht ist ein XP genauso wie ein P4 mit dem 8086 verwand. Diese beinhaltet nämlich nur ein bissel Hauptspeicher, eine ALU , und ein paar Register. Ich glaube "von Neumann Architektur" wird das genannt. Und diese kommt nunmal in einem 8086 genauso vor wie in einem XP. Heutige Prozzzi's sind halt "nur" etwas aufgebohrter. Die Architektur bleibt aber die Gleiche.

nun zum Thema K9

es soll eine asyncrone Cpu werden (hab ich mal gelesen) und das heißt das es Mhz-Zahlen dort nicht mehr direkt geben wird. Weil alle Komponeten unterschiedlich schnell arbeiten. Wie ein Zusammenspiel dort funktioniert weiß ich nicht mehr genau, und falls ich den Artikel irgendwo finde .....schreib ich es noch mal hier

 

[HenryWince]

@ostsee


> nun zum Thema K9 es soll eine asyncrone Cpu werden

Dann müste bis dahin eine passende Design-Methodik geben, die Entwickler das nötige Know-How erworben haben UND es entsprechende Tools auf dem EDA Markt geben. Gelinde gesagt halte ich das für eine Utopie. Alle komerziellen CPUs werden nach wie vor bis auf absehbare Zeit synchrone Logik verwenden (abgesehen von ein paar FIFOs). Alleine schon der Aufwand fuer die Design-Verifikation wäre zu gross.

ASYNC Designs werden sicher mal zu einer wichtigen Technologie, aber bis es so weit ist braucht es schon noch ein paar Jahr(?zent)e. Nichts desto trotz sind SUN, IBM, Phillips und Intel schon länger am Forschen.

BTW. Ich glaube nicht das AMD oder Intel so schnell davon weg geht alte Technologie zu re-usen und aufzubohren bis es nicht mehr geht: Das ist halt einfach viel billiger!

Quote: "Among the actual circuits disclosed at ISSCC 2003 were several 90nm designs from Intel, including a 10GHz RISC core, a 5GHz FPU, and a 5GHz clock-distribution scheme with less than 10ps of skew, meant for a commercial x86 microprocessor."

Mit TRIPS wird IBM auch so schnell nicht von der synchronen Logik weg kommen. D.h. bis 100% ASYNC CPUs auf dem Markt erscheinen dürfte es noch 20 Jahre dauern.

[Siehe auch http://www.cs.utexas.edu/users/cart/trips/]

 

[Ostsee]

Original geschrieben von HenryWince
@ostsee


> nun zum Thema K9 es soll eine asyncrone Cpu werden

ASYNC Designs werden sicher mal zu einer wichtigen Technologie, aber bis es so weit ist braucht es schon noch ein paar Jahr(?zent)e. Nichts desto trotz sind SUN, IBM, Phillips und Intel schon länger am Forschen.

BTW. Ich glaube nicht das AMD oder Intel so schnell davon weg geht alte Technologie zu re-usen und aufzubohren bis es nicht mehr geht: Das ist halt einfach viel billiger!

D.h. bis 100% ASYNC CPUs auf dem Markt erscheinen dürfte es noch 20 Jahre dauern.

[Siehe auch http://www.cs.utexas.edu/users/cart/trips/]

Ich gebe Dir da mal Recht, aber aufgrund von irgendwelchen Gerüchten das AMD ein absolut neues Design auf den Markt werfen will, wurde das mal so spekuliert.Ich habe es bis jetzt noch nicht gefunden, aber es war auf der Site http://chip-architect.com/ . Wie komplex allein ein "extrem" aufgebohrtes K7 design sein kann ..... sieht man ja am Hammer und dessen Verspätung. Und ich selbst rechne mit dem K9 frühestens in 4-5 Jahren.
Vieleicht gibt ja IBM aufgrund der Allianz ja ein bissel Wissen rund um Async. CPU's an AMD weiter

 

[TiKu]

Ich hab mal in einem Bericht gelesen, dass in heutigen (das war vor 2 Jahren oder so) CPUs schon ziemlich viel ohne Takt läuft (das sollte doch dasselbe wie asynchron sein, oder?).
Ob das stimmt, weiß ich nicht, aber falls ja, könnte ich mir schon vorstellen, dass der K9 komplett asynchron wird. Cool wäre es schon.

 

[HenryWince]

> Ich hab mal in einem Bericht gelesen, dass in heutigen (das war vor 2 Jahren oder so) CPUs schon ziemlich viel ohne Takt läuft

Es gibt einige kleinere Building Blocks die in komerziellen CPUs schon ASYNC laufen (v.a. FIFOs). Im Low-Power-Segment gibt es mehr Produke die ASYNC sind. Allerdings ist die Komplexitaet dementsprechend niedrig.

> das sollte doch dasselbe wie asynchron sein, oder?.

Meistens meint man mit Clockless ASYNC, aber prinzipiell würden auch mesochrone Designs darunter fallen (d.h. es gibt kein eigentliches Clock Signal aber die sync/clock info ist implizit Teil der Daten).

Mehr zu ASYNC designs unter:
http://www.cs.man.ac.uk/async/background/

Neben anderen empfehlenswerten Docs, gibts zu Amulet3i auf http://www.hotchips.org/archive/ mehr Infos.

> Cool wäre es schon.
Yep, im wahrsten Sinn des Wortes. So ein Chip dürfte ziemlich wenig El.-Leistung verbraten. Wie gesagt halte ich das aber noch für eine Utopie.

 

[Bokill]

Da könnte man glatt die Heisesuchmaschine dafür nutzen, die hatten in diversen c`ts ab und zu Meldungen zu asynchronen CPU`s.
Ich denke aber dass in absehbarer Zukunft in x86 und AMD64 keine Taktlosen CPU geben wird.

Wie soll man denn so etwas vermarkten?! Jeder User will doch maximale Leistung, auch wenn es technisch möglich ist, denke ich dass solche Taktlosen schwarzen Käfer in irgendwelchen Set-Top-Boxen, Walkmans und ähnlichen drinhocken wird, überall dort wo Rubustheit und Sparsamkeit viel wichtiger sind, Home CPU`s sind alles andere als das.

Aber wer weiss, is halt noch ne lange Zeit

 

[Bokill]

schon.

Jedenfalls kann mans auch in deutsch lesen wenn man seine c`t sammlung pflegt

1. Jörg Wirtgen, Andreas Bleul (jow)
Wie taktlos ...
Die Rückkehr asynchroner Prozessoren
Know-how, Asynchrone Prozessoren, Null Convention Logic, Micropipelines, bounded delay, CSCD, Muller-C-Gate, dual rail, threshold gate, Amulet2e, Titac-2
c't 17/99, Seite 176

http://www.heise.de/ct/inhverz/search.shtml?T=Titac-2&Suchen=suchen

Dazu ein weiterer netter Link mit weiterem kurzen Artikel:

Meldung vom 20.10.1999 16:23
Motorola setzt auf asynchrone Logik
Der Halbleiterhersteller Motorola möchte asynchrone Logik in seinen 32-bit-M*CORE(tm)-Prozessoren und einigen 8-bit-Controllern einsetzen. Zu diesem Zweck hat das Chicagoer Unternehmen eine strategische Allianz mit der Firma Theseus Logic beschlossen.

Theseus ist Erfinder der Null Convention Logic (NCL), die ohne Taktsignale arbeitet und völlig unempfindlich gegenüber Laufzeitschwankungen einzelner Gatter ist (siehe c't 17/99, S. 176). Motorola beabsichtigt, mit dieser Technik Mikrocontroller ("Systems On A Chip") herzustellen, die im Vergleich zu den aktuellen Modellen deutlich weniger Leistung aufnehmen, eine schwächere Störstrahlung abgeben und sich von Temperaturschwankungen unbeeindruckt zeigen. Theseus erhält Zugang zu allen Dokumentationen von Motorola, um daraus NCL-Versionen der Prozessoren und Peripherie-Komponenten zu entwickeln. Die ersten Produkte sind für die zweite Hälfte des Jahres 2000 angekündigt. (Andreas Bleul) (jow/c't)

http://www.heise.de/newsticker/resu...00/default.shtml&words=asynchrone Prozessoren


Sehr nett und zukunftsweisend...

, jedoch eher für den Geode oder Alchemie Prozessor.
http://www.theseus.com/
http://www.theseus.com/FramesTechBene.htm

 

[Bokill]

Sehr nette Perspektiven von Intel, bestimmt hat AMD zum Teil ähnliche Ideen, zumal beide frische Blutinfusionen erhielten in Form von ehemaligen Alpha- Entwicklern.

Der Link ist besonders nett, da weitere Links genannt werden, könnte ich glatt zum Thread "Brutstätten, die Mutter aller CPU`s" hineinpappen.

Intel Tanglewood to Consist of Sixteen CPU Cores?

by Anton Shilov
09/01/2003 | 12:23 PM

Those of you who constantly read news concerning present and future Intel Itanium processors already know that code-named Montecito design scheduled to come in 2005 will have 2 cores. But was not known until now is that the follower of the Montecito presently known as Tanglewood will have as many as 16 cores, News.com reported quoting a source close to Intel Corp.!

Multi-core designs promise to become extremely popular within the next three to five years not only among server CPUs, but also among consumer desktop microprocessors, I believe. A number of cores allow chips to handle a number of threads at the same time, a feature that is supposed to become increasingly important nowadays. Intel is currently offering Hyper-Threading technology for that matter in Xeon and Pentium 4 CPUs, but with more and more complicated tasks a number of cores per chip will be required for successful and rapid operation.

IA64 roadmap has been showing exceptional performance growth since the introduction of the original Intel Itanium processor. It is very logical to expect Intel to continue introducing faster and faster 64-bit microprocessors throughout the decade. There are a number of ways to improve performance of CPUs, including clock-speed increase, addition of extra cores into design, overall architecture efficiency improvements as well as L1, L2 or L3 caches enhancements. According to what we know about future IA64 chips, the Santa Clara, California-based semiconductor giant will perform all the mentioned operations to address even the highest-end servers by its microprocessors with tangibly improved architecture.

As we know, next year Intel is set to launch its Madison 9M code-named processor with 9MB of L3 cache and clock-speed above 1.50GHz. In 2005 the company will launch its Montecito core made using 90nm fabrication process and featuring 2 cores as well as 18MB of L3 cache. In 2006 or 2007 Intel is expected to release Tanglewood, the monster with up to 16 cores, a lot of cache memory and a high clock-speed. The core may be as advanced as next-generation IBM’s Power or Sun’s UltraSparc microprocessors or even faster, I suppose.

Related news:
Intel Tanglewood to Be 10 Times Faster Than Madison.
http://www.xbitlabs.com/news/cpu/display/20030428064454.html

IBM’s Power5-Based Machines Are Nearly Here. Power6 CPU is Enroute
http://www.xbitlabs.com/news/cpu/display/20030402165234.html

Intel Tanglewood to Come After Montecito. Another Monstrous Processor From the IA64 Family
http://www.xbitlabs.com/news/cpu/display/20030327183351.html

IBM and Sun Develop Multi-Threaded Microprocessors.
http://www.xbitlabs.com/news/cpu/display/1046213175.html

Intel’s Dual-Core Itanium “Montecito” to Feature a New Bus and 18MB of L3 Cache.
http://www.xbitlabs.com/news/cpu/display/news6426.html

Intel Changes Itanium Roadmap. Dual-Core CPU from Intel to Appear in 2005.
http://www.xbitlabs.com/news/cpu/display/news6093.html

Look Here, Look There: Alpha Everywhere
http://www.xbitlabs.com/news/cpu/display/news1030.html

 

[HenryWince]

@Bokill

> Sehr nette Perspektiven von Intel, bestimmt hat AMD zum Teil ähnliche Ideen, zumal beide frische Blutinfusionen erhielten in Form von ehemaligen Alpha- Entwicklern.

Naja das ist doch schon ziemlich Asbach den schon weit vor http://www.heise.de/newsticker/data/as-25.06.01-002/ war klar das Compaq die Technologie verscherbelt.

Zum Thema Itanic mit EV8 Technologie empfehle ich http://research.ac.upc.es/pact01/keynotes/emer.pdf
Und dann wäre da noch http://www.theregister.co.uk/content/61/31537.html

Ach ja vergleicht man die Architektur vom Hammer mit der des EV7 (AXP21364) zeigen sich einige Gemeinsamkeiten:

- Reuse des letzten Cores (K7 vs. 21264)
- 64k L1 Cache
- Big L2 Caches (1MB vs. 1.75MB)
- Integrierter Memorycontroller(DualDDR vs. 2 Channel-RDRAM)
- Glueless Direct CPU-to-CPU Interfaces @6.4GB/s (3xHT vs. 4xEV7 Bus*)

*) Maximale Gesamttransferrate pro Node 10GB/s

Nur so am Rande AMD hatt schon ewig lange eine EV6 Buslizenz und HyperTransport eben aus jenem Busprotokoll das für den Alpha entwickelt wurde .

Nähres zum 21364 http://h18003.www1.hp.com/hps/download/Compaq_EV7_Wp.pdf

Andere Technologien die im Hauses DEC ihren Ursprung haben:
VAX -> Das M68k ISA ist stark von der VAX geprägt.
VMS -> der WinNT Kernel ist ähnlich zur VMS Architektur -- kein Wunder, schlieslich kaufte MS mit Dave Cuttler den damaligen Chefentwickler ein. Fehlen halt nur die richtig geilen Dinge wie Cluster und Galaxies

P.S. Vieleicht ist TFP ja wirklich im K9 und steht für Tarantula FP *grins* (http://www.computer.org/proceedings/isca/1605/16050281abs.htm)

 

[Bokill]

Jaaah, geil, so etwas ist doch sehr aufschlussreich!

Suuuuper HenryWince.

Ich zitiere mal das zu Tarantula!

Tarantula: A Vector Extension to the Alpha Architecture
Roger Espasa, Federico Ardanaz, Julio Gago, Roger Gramunt, Isaac Hernandez, Toni Juan, Universitat Politècnica de Catalunya
Joel Emer, Stephen Felix, Geoff Lowney, Matthew Mattina, André Seznec , Compaq Computer Corporation


Tarantula is an aggressive floating point machine targeted at technical, scientific and bioinformatics workloads, originally planned as a follow-on candidate to the EV8 processor. Tarantula adds to the EV8 core a vector unit capable of 32 double-precision flops per cycle. The vector unit fetches data directly from a 16 MByte second level cache with a peak bandwidth of sixty four 64-bit values per cycle. The whole chip is backed by a memory controller capable of delivering over 64 GBytes/s of raw bandwidth. Tarantula extends the Alpha ISA with new vector instructions that operate on new architectural state. Salient features of the architecture and implementation are: (1) it fully integrates into a virtual-memory cache-coherent system without changes to its coherency protocol, (2) provides high bandwidth for non-unit stride memory accesses, (3) supports gather/scatter instructions efficiently, (4) fully integrates with the EV8 core with a narrow, streamlined interface, rather than acting as a co-processor, (5) can achieve a peak of 104 operations per cycle, and (6) achieves excellent ``real-computation'' per transistor and per watt ratios. Our detailed simulations show that Tarantula achieves an average speedup of 5X over EV8, out of a peak speedup in terms of flops of 8X. Furthermore, performance on gather/scatter intensive benchmarks such as Radix Sort is also remarkable: a speedup of almost 3X over EV8 and 15 sustained operations per cycle. Several benchmarks exceed 20 operations per cycle.

Index Terms- Vector Processor, Microprocessor, High Performance, Bandwidth, Power, Instruction Set Architecture, Virtual Memory, Cache Coherency

Hat meine Meinung für TFP bestärkt

 

[HenryWince]

@Bokill

Nimm das mit Tarantula nicht zu ernst! Die Architektur wurde explizit für EV8 SMT entworfen. Allerdings gibt es da ein paar technische Hürden die das Ganze vieleicht nicht ganz so vorteilhaft erscheinen lassen:

* VBox tightly coupled to AXP core design
* Non-unit strides gather/scatter operations (Single word cache => complexity !!!)
* Nur L2 Access (L1 zu klein, nicht Multi-Ported!)
* Cache-Coherence (L1 <=> L2: Mind. 1 L2 Tag Bit mehr)

 

[Bokill]

Ich denke, dass die das auch nicht 1:1 übernommen hätten.

Jedoch finde ich doch sehr verdächtig, dass die Register für die FPU auf dem alten Stand blieben!

Ich schätze, das nachträgliche hineinfrickeln von weiteren Registern ist zu fehlerträchtig und verschmutzt die K8 Architektur, daher meine wilde Spekulation zum K9

Wenn AMD mit dem Power xy und den Alphas und Sparcs miteifern will, müssen sie genau an dieser Stelle den K9 aufbohren.
Auch wenn nun jeder Hersteller seine eigene spezielle Vectoreinheit hineinbackt, so ist doch in bestimmten Fällen eine hohe Rechengenauigkeit gefordert, wenn dann die spätere Fassung von AMD`s wie auch immer geartete FPU/Vectoreinheit, schnell mit hoher Genauigkeit rechnen kann, dann nenne ich dies TFP.

Von TechnicalFloatingPoint (Einheit/Unit)

Aber dein Einwand ist ganz sicher berechtigt, da könnten wirklich Hirngespinste verpflanzt werden, die dann ein unbändiges Eigenleben führen