MMX, SSE und Co.

[MarianSchedenig]

Eine leicht dümmliche Frage: Kann man ein C++-Programm so compilieren, daß relevante Teile sowohl MMX/SSE/usw-optimiert vorhanden sind als auch in reinem x86-Code?

Problem hat sich daraus ergeben, daß ich mich nie so genau über die CPU-Fähigkeiten informiert hab und geglaubt hab, SSE wäre bei allen halbwegs schnellen CPUs sicher dabei. Tagelange Bug-Suche nach Bugreports unserer Beta-Tester haben dann irgendwann den Absturz auf eine einfache Float-Zuweisung eingegrenzt, da hat's dann gefunkt....so ein Athlon Thunderbird kann halt eben kein SSE.

Aber ich nehme doch an, daß moderne Spiele SSE verwenden, sofern vorhanden? Bloß wie? Oder erzeugen die dynamische Libs und linken je nach Prozessor mit der geeignet compilierten?

[gck]

in den intel manuals wird in so einem fall entweder vorgeschlagen, verschiedene binaries zu generieren und zur installation entscheiden, welche zum zug kommt, oder deine variante mit verschiedenen dlls, die dann (dynamisch, je nachdem, was der prozessor kann) geladen werden, oder eine mega-binary, in der es verschiedene versionen der routinen gibt...

der intel c/c++ compiler, den man sich zumindest für linux als "unsupported" version von den intel hp downloaden kann, unterstützt derlei spielerein direkt, gcc glaub ich nicht.

allerdings existiert sse auch in 3 flavors, also sse, sse2 und sse3, genauso wie die 3DNow! extensions von amd, wobei die amd prozessoren dann auch noch teilweise sse versionen können...

btw: es sollte recht leicht sein, rauszufinden, ob abstürze von nicht unterstützten befehlen abhängen, nämlich sofern das os die entsprechenden state transistions unterstützt, dann sollte ein nicht unterstützte Instruktion eine illegal instruction trap generieren, die der debugger auch checken sollte, alles andere sind segfaults und die anderen "üblichen verdächtigen". Punkt ist, illegal instructions (bei rein compiler generiertem code einer hochsprache) können nur von der verwendung eines falschen instructions sets herrühren (dann braucht ihr das nächste mal nicht tagelang suchen)

[MarianSchedenig]

Danke für die Info, werd ich mir wohl doch erst nach der letzten Abgabe genauer anschauen...noch zu viel zu tun, um an Compilerflags rumzubasteln.

btw: es sollte recht leicht sein, rauszufinden, ob abstürze von nicht unterstützten befehlen abhängen, nämlich sofern das os die entsprechenden state transistions unterstützt, dann sollte ein nicht unterstützte Instruktion eine illegal instruction trap generieren, die der debugger auch checken sollte, alles andere sind segfaults und die anderen "üblichen verdächtigen". Punkt ist, illegal instructions (bei rein compiler generiertem code einer hochsprache) können nur von der verwendung eines falschen instructions sets herrühren (dann braucht ihr das nächste mal nicht tagelang suchen)

Stimmt, und das ist mir auch aufgefallen....dummerweise aber hab ich die Fehlermeldung erst genau gelesen, als ich schon selbst die Idee mit SSE hatte. *g* Bin einfach blind davon ausgegangen, daß das ein Segfault sein muß.