# ein Binary für verschiedene CPUs?

## froonk

Hallo,

ich habe nun ein neues Board mit einer neuen CPU und kompiliere daher mein ganzes System neu damit der Vorteil des neuen Prozessors nicht nur der höhere Takt ist.

Dabei kommen mir einige Fragen in den Sinn.

Wenn man jetzt eine Linux Distribution, die nicht alles auf dem Zielrechner kompiliert, betrachtet, kopiert diese doch nur binaries auf die Platte. Diese müssen doch aber für eine breite Palette an CPU's geeignet sein, also zB für den 386'er verständlich sein. Das würde ja aber heissen, dass jeglicher neu eingeführte Befehlssatz seit dem 386'er nur einer kleinen Minderheit zugänglich wäre. Kann also schwer sein. Ich bin mir auch einigermassen sicher, dass Windows(tm) gebrauch von zB 3DNow! macht, oder zumindest Spiele, die auf Windows laufen. Gibt Es also bei jedem kommerziellen Spiel für jeden Prozessor eine eigene Binary? Oder gibt es Compiler, die Binaries erzeugen, die dann verschieden kompilierte Versionen innerhalb einer Datei enthalten, das System irgendwie fragen, welche CPU denn nun hier gerade läuft und dann die jeweils passende Version ausführen?

Ich kann einfach nicht glauben, dass die erweiterten Befehlssätze nur zur geltung kommen, wenn man selbst kompiliert.

Hoffentlich weiss einer von Euch eine Antwort auf diese quälenden Fragen  :Wink: 

mod-edit: Titel aussagekräftiger gestaltet --slick

----------

## Hilefoks

Nun, wenn man alle x86-32-Bit Prozessoren unterstützen möchte muß man auf i386 optimieren. Und ja, - dann wird kein mmx,sse,sse2 oder 3dnow benutzt.

Firmen wie SuSE optimieren allerdings mindestens auf Pentium1. Aber auch SuSE bringt 2 Versionen raus - die normale Pentium und die x86-64Bit optimierte (auf der auch die Pentium-Version laufen würde).

Um dennoch höhere Befehlssätze benutzen zu können muß man dann wirklich verschieden optimierte Bibliotheken erstellen und diese dann dynamisch nachladen. 

Und obendrein kann man z.B. auf Pentium4 optimieren ohne die kompatibilität zum 386'er zu brechen. Dann benutzt man zwar keine neueren Befehle des P4's, allerdings optimiert man seinen Code auf die Pipelines des P4....

Mfg Hilefoks

----------

## equinox0r

 *Hilefoks wrote:*   

> ...allerdings optimiert man seinen Code auf die Pipelines des P4....

 

kannst du mir das der verständnis halber bitte etwas genauer erklären? bin da nicht so bewandert ... thx  :Smile: 

----------

## Hilefoks

 *equinox0r wrote:*   

> kannst du mir das der verständnis halber bitte etwas genauer erklären? bin da nicht so bewandert ... thx 

 

Ob ich das kann? Versuchen kann ichs  :Smile: 

Der Prozessor muß immer eine Reihe von Aktionen ausführen um einen Befehl verarbeiten zu können. Ein sehr dummes Beispiel:

1. Instruktion lesen

2. Instruktion dekodieren

3. Operanden lesen

4. Instruktion ausführen

5. Write-Back (also Ergebnis speichern)

nun ist ein Prozessor nicht eine einzige Funktionseinheit, sondern eine Sammlung verschiedener Funktionseinheiten (FPU,ALU usw.). 

Wenn nun für jede der oben genannten Schritte eine eigene Funktionseinheit zuständig ist, dann könnte man doch schon den nächsten Befehl lesen, wärend der letzte noch in der dekodierung steckt. 

Das schöne an einer Pipeline ist also die höhere Geschwindigkeit, der Nachteil ist allerdings das eine schon gelesende Instruktion komplett abgearbeitet werden muß, auch dann wenn der letzte Befehl einen Sprung verursacht hat und der aktuelle Befehl garnicht mehr benötigt wird.

Da das Zeit kostet implementiert man eine Sprungvorhersage in  die Prozessoren. Somit erkennt der Prozessor das der Befehl einen Sprung ausführen wird und wartet dann auf das Ergebnis ohne die Pipeline mit Müll zu befüllen... 

Nun, das ist jetzt alles sehr grob und damit zum Teil auch falsch (aber verständlicher) beschrieben. Obendrein hat ein Prozessor nicht nur eine Pipeline, sondern gleich mehrere - eine solche CPU nennt man dann eine Superskalare CPU. 

Und eben dies ist in allen CPU-Generationen anders implementiert. So sind  die Pipelines eines P4 z.B. länger als die eines P2.

Mfg Hilefoks

EDIT: Habe gerade mal bei Google geschaut, ob es nicht doch eine gute Seite gibt die es besser Beschreiben kann als ich ... und siehe da

http://www.computerbase.de/lexikon/CPU.

Ansonsten kann ich nur Bücher zum Thema empfehlen. 

http://www.lob.de/cgi-bin/work/framesetneu?flag=new&frame=yes&id=41e60eb585f28

und gleich danach

http://www.lob.de/cgi-bin/work/framesetneu?flag=new&frame=yes&id=41e60eb585f28

----------

## schmutzfinger

@Hilefoks ich habe das schonmal in ner Vorlesung gehört und desswegen weiss ich wovon du redest, nur leider fürchte ich das die meisten Leute mit deinem post recht wenig anfangen können.

@equinox0r lies am besten ein Buch zu Grundlagen der Rechnerarchitektur.

----------

## Hilefoks

Mh, ist das wirklich zu schwer? Ich denke schon das ein etwas technisch interessierter Mensch (so wie alle im Gentoo-Forum) das verstehen könnten.

Allerdings könnte es natürlich ebenso sein das ich einfach nur ein Fachidiot bin der zwar dieses Thema kennt, aber nichts mehr verständlich erklären kann.   :Embarassed: 

----------

## WiredEd

Es gibt dazu einen wunderschönen Artikel in der c't 08/95 ab S. 230 (ich weiss, ist schon älter, aber grundlagentechnisch hat sich seit dem ja nicht mehr allzuviel getan   :Shocked:  )

Vielleicht kennst Du jemanden der den Artikel auf cd-rom hat. Wenn nicht, schick mir ne PM mit Deiner Mailadresse, dann bekommst Du ihn von mir.

(... und ja, das A20-Gate wird auch erwähnt)

----------

## Earthwings

 *Hilefoks wrote:*   

> Mh, ist das wirklich zu schwer? Ich denke schon das ein etwas technisch interessierter Mensch (so wie alle im Gentoo-Forum) das verstehen könnten.
> 
> Allerdings könnte es natürlich ebenso sein das ich einfach nur ein Fachidiot bin der zwar dieses Thema kennt, aber nichts mehr verständlich erklären kann.  

 

Da kann ich doch mal gerade das Waschmaschinen-Beispiel aus meiner alten TI-Vorlesung hervorkramen *g*

Also, man stelle sich eine Pipeline vor wie den Waschvorgang mit einer Waschmaschine. Gemessen wird der Durchsatz, d.h. mehr gewaschene Wäsche bedeutet auf den Prozessor übertragen mehr Geschwindigkeit.

Jetzt wäre eine Möglichkeit, die Wäsche aus dem ganzen Haus einzusammeln, diese dann zu sortieren, sie anschließend in die Waschmaschine zu stopfen und nach Ende des Waschvorgangs trocknen zu lassen, wenn sie getrocknet ist bügeln und ab in den Schrank damit. Sobald man fertig ist, kommt die nächste dreckige Wäsche dran. Das ist die Version ohne Pipeline.

Um eine Pipeline zu haben, nehm ich einfach ein paar mehr Leute, die die verschiedenen Vorgänge durchführen. Einer holt die Wäsche, einer sortiert sie, einer bügelt, und die Waschmaschine kann ununterbrochen waschen. Die Geschwindigkeit wird jetzt vom langsamsten Glied der Waschkette (also hier wohl der Waschmaschine) bestimmt, nicht mehr von der Summe aller.

----------

## Hilefoks

 *Earthwings wrote:*   

> Da kann ich doch mal gerade das Waschmaschinen-Beispiel aus meiner alten TI-Vorlesung hervorkramen *g*

 

Oh, das Beispiel ist wirklich cool! 

Danke, Hilefoks

----------

## Tobiking

Hab vor nem Jahr oder so mal bisschen über SSE und 3DNow informiert. Und hab davon noch nen bisschen in Erinnerung.

Also SSE, 3DNOW und die anderen optimierungen die schon grob erklärt wurden sind zwei verschiedene paar Schuhe. Fakt ist das Windows selbst kein 3DNow SSE (MMX?) nutzt.  Und ich will mal behaupten das außer mplayer und nen paar andere Programme aus ähnlichen Bereich oder Spiele keins dieser Features unter Linux nutzt.

Hier wird es flau mit dem Wissen  :Very Happy:  :

3DNow und SSE werden grundlegend auch Multimedia Register genannt und diese Register werden in 64 oder 128 bit angesteuert aber wie 32 bit genutzt. Das heißt das dort mehrere Werte hineinpassen und man so mit mehreren Werten gleichzeitig Rechnen kann was irgendwie schneller ist. Das ganze bringt aber durch die initialisierung etc. erst etwas sobald sehr viele Rechnungen durchgeführt werden wie es nunmal z.B. in Spielen vorkommt beim Multiplizieren der Vertizes mit einer oder Mehreren Matrizen für Rotation Projektion etc. Deswegen gibt es im DirectX SDK SSE und 3DNow optimierte Funktionen oder Spiele nutzen eigene FUnktionen. Fakt ist aber das vorher immer "manuell" geprüft wird was vorhanden ist und je nachdem die richtige Funktion aufgerufen wird.

----------

## Hilefoks

MMX: Multi Media Extension. Erste Erweiterung die SIMD implementiert (Single Instruction Multiple Data) wodurch ein 32Bit Prozessor auch 64 oder 128Bit Register lesen und schreiben kann, nur nicht in einem Stück. Allerdings kann die MMX-Erweiterung in einem eine Operation auf diesen Registern durchführen. MMX brachte acht neue Register mit je 64-Bit.  

3DNow: Nutzt die gleichen Register wie MMX, allerdings mit anderen Befehlen.

BTW: Die MMX-Erweiterung führt nicht wirklich neue Register ein, sondern nutzt die der FPU (80Bit) wodurch man nicht FPU und MMX gleichzeitig nutzen kann.

SSE: Streaming SIMD Extension. Mit SSE wurden 70 neue Befehle eingeführt.

SSE2: Bringt wieder einen haufen neuer Befehle und die Möglichkeit auch mit den MMX Befehlen 128Bit Register zu benutzen.

AMD: AMD implementiert zu Teil nicht alle Befehle der SSE und SSE2-Instruktionen in ihren Prozessoren. Deshalb muß man als Programmierer (in Assembler) aufpassen und nicht nur prüfen ob eine Erweiterung vorhanden ist, sondern u.U. auch welcher Prozessor diese Umsetzt.

Alle Eweiterungen machen aber nur Sinn wenn man viele große Daten verarbeiten möchte und es u.U. nicht auf die Genauigkeit, sondern vielmehr auf die Geschwindigkeit ankommt. So z.B. bei Spielen oder der decodierung von Video's.

Mfg Hilefoks

----------

## marc

Einen guten Einstieg bekommt man auch kostenlos.

http://www.galileocomputing.de/openbook/kit/

Da wird gut erklärt wie die Hardware arbeitet und wie ein Prozessor funktioniert. Sollte man sich als Technikinteressierter ruhig mal durchlesen. Da ich kein Informatik studiert habe aber dennoch interessiert bin, suche ich mir hier und da immer mal wieder ein paar Infos zusammen.

Man muss ja keine Details lernen, aber das Prinzip zu verstehen ist schon nicht schlecht.

Noch mehr Bücher

----------

## equinox0r

ach ihr seids schon dolle hier  :Smile:  *einfach mal sagen muss*

----------

## zinion

 *equinox0r wrote:*   

> ach ihr seids schon dolle hier  *einfach mal sagen muss*

 

Ja siha dat ham ja auch alle Gentoo installiert  :Razz: 

----------

## Jtb

 *Hilefoks wrote:*   

>  *Earthwings wrote:*   Da kann ich doch mal gerade das Waschmaschinen-Beispiel aus meiner alten TI-Vorlesung hervorkramen *g* 
> 
> Oh, das Beispiel ist wirklich cool! 
> 
> 

 

wer das auch noch grafisch haben will: 

http://www.informatik.tu-darmstadt.de/gdi-2/folien/GdI2-Kap06.t1.pdf

----------

## c07

Am grundlegenden Befehlssatz hat sich ja seit dem 386er nicht mehr viel getan. Ist also kein großes Problem, Code zu erzeugen, der auch noch auf einem 386er läuft, ohne auf aktuellen Maschinen zu viele Nachteile zu haben. Auf Spezialbefehle (inkl. MMX u.Ä.) kann man immer noch zurückgreifen, wenn man für den wenigen Code, wo das sinnvoll ist, mehrere Versionen hat und zur Laufzeit die geeignete wählt. Solcher Code ist dann meistens eh handoptimierter Assembler.

Einzige Ausnahme (bis zum Athlon64) ist das CMOV (ab 686er), das auch im normalen Code Vorteile bieten kann (erspart eine Verzweigung mit womöglich falscher Sprungvorhersage). Aber viele Distributionen setzen heut eh mehr als einen 386er voraus (komischerweise ist ausgerechnet ein 586er als Minimum üblich).

Ein wichtiger Unterschied bei den Optimierungen ist noch die relative Geschwindigkeit der einzelnen Befehle. Normalerweise führen viele Wege zum Ziel, und je nach Prozessor kann ein anderer der schnellste sein.

----------

## equinox0r

das weiss ich auch noch von "früher", da gabs von einigen spielen (z.b. mdk) für jeden prozessor eine eigene version die versch. prozessormodelle unterstützt hat (z.b. mmx)...

das waren noch zeiten *schwelg*

----------

## schachti

Man kann optimieren, und man kann optimieren.   :Laughing: 

Was ich meine: Der gcc hat zum Beispiel die Optionen -mtune und -march. Sagt man -mtune=athlon-xp, so wird Code generiert, der auch auf einem 386'er läuft, der aber so optimiert ist, daß er auf einem Athlon XP möglichst schnell läuft. Sagt Du -march=athlon-xp, so wird der Code so optimiert, daß die Möglichkeiten des Athlon XP voll ausgeschöpft und Befehle benutzt werden, die Vorgängermodelle in der Regel nicht bieten (3D Now!, SSE, MMX usw., vielleicht auch Optimierung der Register).

----------

## JoHo42

Hi Leute,

das der C Code für den jeweiligen Prozessor optimiert werden muß ist klar.

Aber wie ist das mit AMD?

AMD ist 386 / x86 kompatibel OK soweit so gut.

Das heißt Windows läuft auf einen AMD.

Jetzt ist aber Windows für ein Intel  i386 bzw Pentium Optimiert (denke ich mir mal),

oder besser für den Befehlssatz der Prozessoren.

Jetzt kommt AMD daher und will ein Stück dieses Marktanteils für sich

einstecken.

Jetzt muß AMD ihre Prozessoren 386 / x86 kompatibel bauen.

Das heißt die kennen nur den Befehlssatz der schon veröffentlicht ist und

nicht den Befehlssatz den Intel  als nächstes einbaut.

Nur mal angenommen M$ arbeitet mit den Intel zusammen.

Dann sagt M$ wir brauchen neue Multiplikationsbefehle um ihre Software schneller

Arbeiten zu lassen.

AMD kennt die neuen Befehle nicht.

Um Windows schneller laufen zu lassen, können die nur die bekannten Befehle höher

Taken. (daher auch die große Hitzeentwicklung der Prozessoren zumindestens for ein paar Jahren)

Woher kommt eigentlich das Gerücht, dass AMD besser für Spiele sein soll.

Auf den Verpackungen von GAMES steht drauf Vorraussetzung: Pentium3 MMX Technology.

In einem AMD steckt keine MMX Technology. Die ist nur in einem Intel Prozessor drin.

Vondahr kann der für Spiele auch nicht besser sein.

Oder verstehe ich da was grundlegendes Falsch?

Für Gentoo ist der Prozessor egal aber bei Windows?

Das heißt jetzt nicht das AMD nicht geht.

Ich denke nur das die ihre Geschwinigkeit über die Taktung machen und weniger über die

Befehlssätze.

Gruss

----------

## psyqil

 *JoHo42 wrote:*   

> Oder verstehe ich da was grundlegendes Falsch?

 Ja.  :Razz:  Mein AMD hat sehr wohl MMX, und ist bei gleicher Taktung schneller als ein Pentium, deshalb ja die neuen Bezeichnungen, die mit MHz nichts mehr zu tun haben. Der x86-Befehlssatz ist ja auch schon was älter und kein Staatsgeheimnis. Das AMD besser für Spiele sein soll, kommt glaube ich aus der Zeit, als MMX keinem was gebracht hat, 3DNow aber schon...

```
$ cat /proc/cpuinfo

processor       : 0

vendor_id       : AuthenticAMD

cpu family      : 6

model           : 10

model name      : AMD Athlon(tm) XP 2600+

stepping        : 0

cpu MHz         : 1912.984

cache size      : 512 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 1

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse pni syscall mmxext 3dnowext 3dnow

bogomips        : 3784.70
```

----------

## WiredEd

Es hat in den vergangenen Jahren immer wieder Patentaustauschabkommen gegeben zwischen Intel und AMD. Zuletzt zum Beispiel hat Intel den AMD 64-bit Befehlssatz bekommen, der sich ja jetzt auch in den neusten Pentium IV Prozessoren befindet, und es deren Besitzern ermöglicht das 64Bit-Windows laufen zu lassen, das eigentlich für AMD entwickelt worden ist. Im Gegenzug durfte AMD dann SSE2 und andere Dinge in ihre Prozessoren einbauen.

Tatsächlich hat AMD damals 3DNow als "konkurrenz" zu Intels MMX eingeführt. Aber schon seit längerem, ist auch in den AMD-Prozessoren MMX zu finden (wenn ich mich richtig erinnere seit Einführung des Athlon).

Und tatsächlich ist Microsoft in den letzten paar Jahren vorsichtig etwas näher an AMD herangerückt, da Intel einiges in Linux investiert hat (z.B. hat Intel ja die eigene C-Compiler-Collection nach Linux Portiert). So wollte Micro$oft einen Warnschuss vor den Bug von Intel setzten.

Edit:

Und AMD ist deshalb besser zum Spielen geeignet, weil man nach der Anschaffung des Rechners auch noch das nötige Geld über hat, um sich die Spiele leisten zu können!  :Shocked: 

----------

## JoHo42

OK an mir sind einige Entwicklungen vorbei gegangen.

Gruss

----------

## Chrystalsky

so schwer ist das wirklich nicht, wenn man sich damit befasst, also ich meine jetzt mal die Grundlagen zu verstehen, wie eine CPU arbeitet etc. komplizierter wird es dann, wenn man mehrere Architekturen kennt und dort in ASM programmiert, ist immer so eine Sache mit dem durcheinander kommen....

Für alle, die sich hier ein wenig interessieren, kann ich einen Pisc empfehlen, die sind super einfach von Aufbau und auch der Befehlssatz hält sch in Grenzen  :Smile:  und man kann doch schon einiges damit anstellen.... Ich habe mir mal eine Uhr damit zusammengebaut und noch weitere Dinge  :Smile: 

----------

## hoschi

 *Hilefoks wrote:*   

> Mh, ist das wirklich zu schwer? Ich denke schon das ein etwas technisch interessierter Mensch (so wie alle im Gentoo-Forum) das verstehen könnten.
> 
> Allerdings könnte es natürlich ebenso sein das ich einfach nur ein Fachidiot bin der zwar dieses Thema kennt, aber nichts mehr verständlich erklären kann.  

 

Ich kenne nur die einfachsten Grundsätze der Shell-Programmierung, aber dank meiner Hardwarevernerdung war dein Text überhaupt kein Problem. Na ja, ich habe eigentlich schon vorher gewusst wie die Antwortet lautet.

Das große Problem von Intel ist z.B. die extrem langen Pipelines (damit lässt sich der Takt schnell steigern), aber gleichzeitig wurde die Sprungvorhersage seit dem Pentium-3 nicht mehr verbessert. AMD fährt genau andersrum, die Pipeline des Athlon64 müsste in etwas lediglich halb so lang sein, wie die des Pentium4 und die Sprungvorhersage wurde z.B. immer wieder verbessert (mit dem Athlon-XP auf jeden fall).

Mit dem Pentium-M fährt Intel wieder mit einen kürzeren Pipeline (weniger Takt), aber einer besseren Sprungvorhersage als der Pentium3 (der Vater des Pentium-M).

Der Prescott ist ein Paradebeispiel für den Intelschen Pipelinegau, der hat alleine fast eine doppelt so lange Pipeline wie der Northwood, der Takt steigt. Die Sprungvorhersage ist aber immer noch die vom Pentium3.

Jetzt kommt der Knackpunkt, eine Pipeline ist wie eine Fließband.

Je kürzer das Fließband, also je mehr Handwerksarbeit, desto flexibler, aber allgemein langsamer.

Je länger das Fließband, um so schneller geht alles, aber alles ist unflexibel.

Mit der Sprungvorhersage kann man sich aus diesem Dilemma befreien, AMD hat das recht sauber erledigt, Intel nicht.

Intel ging es nur um den Takt, und um Leistungsverluste auszugleichen hat man dann auf Kosten des Gewinns den Level2-Cache vergrößerst usw. also mit reine Rohpower gearbeitet.

Dass ist der Grund warum der Athlon64 und der Pentium-M so erfolgreich sind, und eine so hohe Pro-Takt-Leistung haben.

Und warum der Pentium4-Prescott eine Totgeburt war, die in Benchmarks nicht mal gegen den Northwood ankamm, zum Teil sogar den kürzeren gezogen hat.

Pipeline = Flieband, Produktionsstraße

Sprungvorhersage = der Vorarbeiter

Ich bin auch nur Laie, aber so dürfte es verständlich sein.

PS: Außerhalb davon laufen wie die Befehlssätze, Stromsparfeatures usw.

----------

## hoschi

Intel hat aber noch ein paar Trumpfkarten, z.B. die eigenen Hochoptimierten ICC-Compiler und die Mitarbeit am GCC (hier arbeitet AMD aber auch irgendwie mit), was auch logisch ist, der GCC ist auch außerhalb von GNU einer der am stärksten verwendeten Compiler, und sehr schnell (der ICC dürfte trotzdem überlegen sein).

Der Pentium-M rult alles weg, sprichwörtlich, dagegen wird der Turion64 aber sicher bald auch Akzente setzen.

AMD wird den lukrativisten Markter der 2000er Jahre (neunziger war irgendwie einfacher...), die Laptops, nicht Intel allein überlassen.

Und jetzt wo IBM den Cell ins Feld führt, Apple war hier nur das erste Opfer, ändert sich ab 2006 sicher einiges.

Intels Linux-Support ist inzwischen einwandfrei, da kann man wirklich gar nichts mehr sagen.

Vom Prozessor, über Chipsatz, Grafik bis Wlan läuft alles, sauber mit Open-Source, direkt im Kernel/Xorg, ohne Binarys.

Klar dass das Gatie sauer wird, aber das wird ihm auch nicht mehr viel helfen.

Ich freue mich auf 2006/07, dass wird seit 2003 das interessanteste Jahr.

Dual-Core, Cell, OpenGL-Desktops, DDD3-Ram, PCI-Express setzt sich durch, Mobile-CPUs für den Desktop...lecker

Stellt sich nur die Frage wer am Ende der Gewinner wird.

----------

