verständnisfrage: asm nur für bestimmte cpus
-
hall eine frage:
Wenn ich etwas in Assembler programmiere, dann kann ich das ja nicht allgemeien halten weil es nur für bestimmte Prozessoren greift.das kann ich mir so in der praxis gar nicht vorstellen, dass hieße ja das einige Programme/Spiele unter bestimmte Przessoren nicht laufen würden oder wie machen die das, dass der assemblercode auf möglichst allen computern läuft?
-
blaukopf schrieb:
das kann ich mir so in der praxis gar nicht vorstellen, dass hieße ja das einige Programme/Spiele unter bestimmte Przessoren nicht laufen würden oder wie machen die das, dass der assemblercode auf möglichst allen computern läuft?
Gar nicht. Rat mal wieso es Hochsprachen gibt
-
also hab ich recht und es ist scheiße in assembler zu programmieren weil es dann nicht alle nutzen können?
-
blaukopf schrieb:
also hab ich recht und es ist scheiße in assembler zu programmieren weil es dann nicht alle nutzen können?
Nö. Assembler ist eben Architekturabhängig. x86 Assembler ist eben nur für x86 CPUs. Darum ist es noch lange nicht "scheisse"...
-
ist das der grund warum es programme in 32 und 64bit versionen gibt?
-
Wenn wir schon einmal dabei sind: Die meisten Compiler unterstützen gar nicht die neusten Instruction Sets oder wie muss ich das sehen?
Benutzt .NET die neusten wenn die Sprache aus dem IL "übersetzt" wird?
Danke im Voraus
Das hat mich schon immer interessiert.
-
blaukopf schrieb:
hall eine frage:
Wenn ich etwas in Assembler programmiere, dann kann ich das ja nicht allgemeien halten weil es nur für bestimmte Prozessoren greift.das kann ich mir so in der praxis gar nicht vorstellen, dass hieße ja das einige Programme/Spiele unter bestimmte Przessoren nicht laufen würden oder wie machen die das, dass der assemblercode auf möglichst allen computern läuft?
Hallo,
Überlege mal wieviele verschiedene CPU's im normalen Handel erhältlich sind, dann erübrigt sich deine Frage.
Gruß Nicky
-
Wenn in Assembler programmiert wird oder eine Hochsprache kompiliert wird dann werden meist die Befehle der CPU genutzt die auf allen x86 oder x64 CPU vorhanden sind. Somit läuft dann das Programm, egal ob nun x86, x64 Intel, AMD, VIA etc..
Bei besonders kritischen Stellen kann man dann immer noch spezialisierte Befehle der CPU einsetzten, da wird halt vorher geprüft ob dies von der CPU unterstützt wird und wenn nicht halt wieder auf den Standardbefehlssatz der x86-CPUs zurückgegriffen.
Wenn man natürlich den x86 Kompatiblen Bereich verlässt und z.B für ARM programmiert, so läuft dies wohl in den meisten Fällen auf eine Neuimplementierung zurück. Hier kommen dann die Hochsprachen zum tragen, wo "nur" neu kompliliert werden muss.
Wenn für 64Bit kompiliert oder direkt programmiert wird, dann nur weil Fähigkeiten der 64Bit Architektur sinnvoll für das Projekt ist. Ich glaube sicherheitstechnisch haben die 64bitter auch nen Vorteil, aber meine Assemblerkenntnisse sind noch aus den 80iegern und kurz mal x86 Realmode, also nicht gerade auf den neusten Stand.
Aber hier gibt es sicherlich ne menge Experten, die dir das viel genauer erklären können.
-
Die x86/x64-Architektur (siehe z.B. auch Wikipedia) hat im Wesentlichen ein standardisiertes Set von Instruktionen (andere architekturen mit einem komplett anderen Standardset von Befehlen waeren z.B. ARM oder MIPS). Solange in deinem PC also ein x86/x64-kompatibler, halbwegs aktueller Prozessor steckt, laufen die meisten Programme.
Praktisch wird meist irgendwann am Anfang der Programme geprueft, auf welcher CPU sie nun genau laufen, bzw. welche Befehlssaetze, die ueber den x86-Standard hinausgehen, diese unterstuetzt (MMX, SSE und wie sie alle heissen).
Abhaengig davon, welche erweiterten Befehle unterstuetzt werden, werden dann oft verschiedene Programmteile, die die eine oder andere Befehlssatzerweiterung benutzen oder eben nicht, zwecks beschleunigtem Programmablauf, ausgefuehrt.
Dass hier Probleme "vorprogrammiert" sind, ist wohl offensichtlich.
z.T. wird bei neueren Programmen die oben genannte genaue Pruefung von unterstuetzten CPU-Befehlen auch vernachlaessigt.Beispiel:
Auf meinem 15Jahre alten 450MHz K6-3 crasht VLC in Windows mit einem schweren Ausnahmefehler, da vor Auftauchen von nicht Pentiumkompatiblen Befehlen (cmov) nicht geprueft wird, ob diese auch unterstuetzt werden.
-
blaukopf schrieb:
das kann ich mir so in der praxis gar nicht vorstellen, dass hieße ja das einige Programme/Spiele unter bestimmte Przessoren nicht laufen würden oder wie machen die das, dass der assemblercode auf möglichst allen computern läuft?
Unter GNU/Linux Distributionen ist die gängige Praxis so, dass man sich für eine bestimmte CPU entscheidet, wie z.B. Pentium II oder von AMD xyz und alle Programm-Packete, Kernel, Treiber werden für diese eine CPU baut. Man entscheidet sich sozusagen für einen gemeinsamen Nenner.
Bei manchen Linux-Distributionen dagegen ist es möglich, in einer Konfigurationsdatei die Compiler-Parameter einzustellen wie z.B. unter Gentoo in /etc/make.conf. Bei der Installation von Gentoo kann man dort die CPU (-mtune, -march), Optimierungsstufe (von -Os bis -O3), Befehlsatz (SSEx) und andere Parameter wie -g0 (keine Debug-Symbole) und was einem so alles einfällt und von gcc/g++ akzeptiert wird, einstellen. Dann kann man das ganze System neu bauen lassen und bekommt danach ein System, in dem jedes Programm, Bibliotheken usw. für deine CPU optimiert wurden.
Zusätzlich kann man Linux-Kernel manuell bauen und im System installieren. Bei der Konfiguration des Kernels gibt es Optionen wie Optimize for Size (-Os) oder Optimize for Speed (-O2) und die CPU-Familie vom alten 80386er bis, glaube ich, Prescott - man kann also Kernel und Treiber für deine CPU optimieren lassen (und wenn man schon bei der Konfiguration des Kernels ist, kann man auch alle unnötigen Treiber rausschmeißen, die man im System nicht braucht und bekommt einen schlanken Kernel).
Unter Linux hat man also viele Freiheiten, die unter Windows nicht möglich sind. Die Frage ist nur, ob man es ausprobieren will und bereit ist, neues zu lernen. Siehe auch hier http://www.c-plusplus.net/forum/298633-full (Warum Linux?)
-
Es kommt ein bißchen darauf an. In der Mikrokontrollerwelt gibt es viele verschiedene Prozessoren, die sich auch technisch mehr oder weniger stark unterscheiden, da ist man dann ganz froh, die ein oder andere Hochsprache (meist C) benutzen zu können, weil der Assemblercode jedesmal anders ist, der Hochsprachen Code bleibt dagegen weitgehend der gleiche.
Aber Hardwarestrukturen von Prozessoren sind aber auch in gewisser Weise ähnlich. Die Frage ist dann, wieviel man anpassen muss. Und letztlich gibt es auch ganz nette Inlineassembler- oder Metasyntaxlösungen, wie beim gas, oder man schreibt sich Übersetzter.
Bei Spielen ist es auch ganz oft so, dass das Microsoft-Team spezielle Patches für Spiele zusammenschreibt, d.h. im wirtschaftlichen Sinne. Windows selbst kann man als leistungsfähigen Multiemulator betrachten. Die Intelprozessoren sind untereinander unterschiedlich, aber sie haben Kompatibilität, ohne die sie nicht so erfolgreich geworden wären. Man kann nach wie vor Dos-Betriebssysteme laden, oder 32 Bit Programme unter 64bit Systemen laufen lassen.
In den 90ern gab es eine Übergangszeit, von Dos nach Windows. Hier mussten spezielle Dos-Extender (z.B. http://de.wikipedia.org/wiki/DOS_Protected_Mode_Interface ) geladen werden, damit die Programme (im Protected Mode) laufen.
-
justchris schrieb:
Ich glaube sicherheitstechnisch haben die 64bitter auch nen Vorteil
Haben sie. ASLR (Adress Space Layout Randomization) ist hier aufgrund des größeren Adressraums natürlich bedeutend wirkungsvoller.
Ein weiterer Vorteil bei der Distribution von Binarys für x86-64-Systeme ist, dass man das Vorhandensein von SSE2 voraussetzen kann. Das kann man bei 32-Bit-Builds nicht einfach machen. Der größte gemeinsame Nenner im Featureset liegt dort viel tiefer.
