Assembler Code Portabel?
-
Hi!
Mit Assembler habe ich mich direkt noch nicht befasst, vorher wollte ich nämlich nochmal fragen, wie das mit Assemblerprogrammen auf verschiedenen Computern ( CPU'S mit unterschiedlichem Befehlssatz ) aussieht. Ausserdem würde mich interessieren ob man Programme, die keine OS spezifischen Funktionen ( also nur direkt den Befehlssatz der CPU nutzen ? ) beinhalten, auf verschiedenen Plattformen laufen.Das wärs erstmal.cya.
-
Hi.
Wenn Du damit erweiterte Befehlssaetze, wie spezielle 586-Instruktionen o.ae. meinst, ist das ein eher geringes Problem... Es laesst sich leicht feststellen, was fuer eine CPU im PC steckt und demnach verhindern, dass bestimmte Opcodes, die vom System nicht unterstuetzt werden ausgefuehrt werden.
Anders sieht das natuerlich bei CPUs mit komplett andren Befehlssaetzen aus.
Da Assembler-Programme nur aus CPU-Instruktionen bestehen sind diese nicht zu verschiedenen CPUs kompatibel.Kompatibilitaet von Assemblerprogrammen zu verschiedenen OS gibt es auch nur aeusserst eingeschraenkt. Codes fuer Protected-Mode-Systeme (zB. Windows oder Linux) sind nicht zueinander kompatibel, da diese nicht ohne Systemspezifische Funktionen funktionieren koennen und zusaetzlich noch spezielle Dateiformate verwenden.
Das ganze funktioniert hoechstens bei Realmode-Binaries (zB. fuer DOS und aehnliche Systeme)
Diese kommen zwar auch nicht gaenzlich ohne Systemcalls aus (zB. zum Beenden eines Programms), es laesst sich aber feststellen, welches System gerade installiert ist und dementsprechend verfahren.
-
Danke! Das wollte ich wissen.Doch macht es dann überhaupt sinn Assemblerprogramme zu schreiben wenn man doch sowieso für jede CPU mit anderem Befehlssatz (intel, AMD ? )das programm neu schreiben muss? Was macht Assembler so besonders? Für mich wars immer so ne dunkle Ecke in der Abteilung der Programmiersprachen.Aber es muss doch auch Vorteile haben sonst wäre es ja schon "ausgestorben", oder ist es das bereits?
cya
-
Alle PC CPUs - egal ob Intel oder AMD - benutzen den selben Grund-Befehlssatz (x86).
Zusaetzlich gibt es dann noch 3D-Now fuer AMD und SSE2 fuer aktuelle Intel CPU. (KA, ob neuere AMD CPU auch schon SSE2 unterstuetzen...)
Wie gesagt, muss man fuer solche unterschiedlichen CPU die Programme nicht vollkommen neu schreiben.
Notwendig ist assembler zu Programmierung einiger Micro-controller oder zur OS-Entwicklung.
-
Nochmals danke! Ein letztes noch: in wie weit kann man mit Assembler die Hardware ansprechen? (direkt, soll heissen per Kernel)
-
Original erstellt von Nobuo T:
(KA, ob neuere AMD CPU auch schon SSE2 unterstuetzen...)Tun sie.
-
Original erstellt von <n0Ob>:
Nochmals danke! Ein letztes noch: in wie weit kann man mit Assembler die Hardware ansprechen? (direkt, soll heissen per Kernel)Zum einen blenden bestimtme Hardwarekomponenten einen Teil ihres SPeichers in den Hauptspeicher ein. Prominentestes Beispiel ist da die Grafikkarte, die den Grafikspeicher zumindest für Text/CGA/EGA/VGA(/SVGA?) in den Speicher ienblendet und man durch schreiben an bestimmte Speicherstellen dann etwas darstellen kann. Außerdem hat die CPU die in/out-Befehle womit man Daten (in Form von bytes/words/dwords) an "Ports" schicken kann, eine Art Adressen nur für Geräte. Ein sehr prominentes Beispiel sind hier die Soundblaster-Karten die imemr den "Port" 220h beanschlagten. Aber auch viele andere Geräte werden über Prots kontrolliert, das gilt genauso für Mainboardkomponenten wie DMA-Controller.
Um ein bestimmtes Gerät anzusprechen muss man dann natürlich wissen, was man an welchen Port shcicken muss um etwas zu tun.
-
@Lars: war ja abzusehen, thx
Uebers Kernel laesst sich die Hardware mit Asm oder C gleich gut ansprechen. (Es handelt sich hier schliesslich nur um Aufrufe von Systemprozeduren - die sehen in beiden Sprachen praktisch gleich aus)
-
Ach, wenn das so gemeint ist mit "per Kernel"
Da ruft man genau dieselben Funktionen auf wie in C auch. Man packt nur die Parameter anders hin. Sprich es macht keinen Unterschied ob du machst
putc(65);
oder
push 65
call putc[ Dieser Beitrag wurde am 27.04.2003 um 21:41 Uhr von TriPhoenix editiert. ]
-
Danke für die antworten, ich habe jetzt nach einer Umgebung fürs Assemblerprogrammieren gesucht, bin auf MASM gestossen, sieht ja auch ganz ausreichend aus ODER? Ich hab auch mal davon gehört, dass man Programme DISASSEMBLIEREN kann.was heisst das genau? wird das komplette programm (die EXE) zerlegt und in assembler code zurückübersetzt? oder kann nur ein teil disassembliert werden?
cya
-
Original erstellt von <N0Ob>:
Danke für die antworten, ich habe jetzt nach einer Umgebung fürs Assemblerprogrammieren gesucht, bin auf MASM gestossen, sieht ja auch ganz ausreichend aus ODER?Jop, der MASM ist recht umfangreich, damit kann man eigentlich sowiet ich weiß alles anstellen was man will.
**
Ich hab auch mal davon gehört, dass man Programme DISASSEMBLIEREN kann.was heisst das genau? wird das komplette programm (die EXE) zerlegt und in assembler code zurückübersetzt? oder kann nur ein teil disassembliert werden?
**Ein disassembler versucht so weitgehend wie möglich alles in Assemblercode zurückzuüebrsetzen. Das klappt mal mehr mal weniger gut, weil es immer schwierigkeiten gibt, zu unterscheiden ob etwas nun Code ist oder nicht. Am besten machen es die Debugger, weil die wenn man das Programm anhält ja sehen können wo es gerade ist und so sicher sind, dass dies nun zu disassemblieren ist.
-
bin wunschlos glücklich. (vorerst.. :p )
-
Original erstellt von <n0Ob>:
**Hi!
Mit Assembler habe ich mich direkt noch nicht befasst, vorher wollte ich nämlich nochmal fragen, wie das mit Assemblerprogrammen auf verschiedenen Computern ( CPU'S mit unterschiedlichem Befehlssatz ) aussieht. Ausserdem würde mich interessieren ob man Programme, die keine OS spezifischen Funktionen ( also nur direkt den Befehlssatz der CPU nutzen ? ) beinhalten, auf verschiedenen Plattformen laufen.Das wärs erstmal.cya.**
Assembler Code ist immer nur für eine spezielle CPU Familie gültig.
Als Beispiel sei folgende minimale C Routine gewählt:
void my_add_function(int* value) { *value += 42; }
Für eine 32bit Intel- oder AMD x86 CPU sieht das ganze in Assembler so aus:
.text .align 2 .gobl my_add_function .def my_add_function; .scl 2; .type 32; .endef my_add_function: pushl %ebp movl %esp, %ebp movl 8(%ebp), %eax addl $42, (%eax) popl %ebp ret
Für eine 64bit UltraSPARC III musst du dagegen ganz andere Mnemonics verwenden:
.section ".text" .align 4 .global my_add_function ,type my_add_function,#function my_add_function: ld [%o0], %g4 add %g4, 42, %g1 retl st %g1, [%o0]
Und für eine 32bit PowerPC CPU sieht das ganze noch einmal ganz anders aus:
.text .align 2 .globl _my_add_function _my_add_function: lwz r2, 0(r3) addi r0, r2, 42 stw r0, 0(r3) blr
-
Da hatten sich doch glatt ein paar kleinere Schreibfehler eingeschlichen...
Hier das korrigierte Posting (ich sollte es mir mal angewöhnen, mich einzuloggen, damit ich meine Postings auch nachträglich noch editieren kann...)Assembler Code ist immer nur für eine spezielle CPU Familie gültig.
Als Beispiel sei folgende minimale C Routine gewählt:
void my_add_function( int * value) { *value += 42; }
Für eine 32bit Intel- oder AMD x86 CPU sieht das ganze in Assembler so aus:
.text .align 2 .gobl my_add_function .def my_add_function; .scl 2; .type 32; .endef my_add_function: pushl %ebp movl %esp, %ebp movl 8(%ebp), %eax addl $42, (%eax) popl %ebp ret
Für eine 64bit UltraSPARC III musst du dagegen ganz andere Mnemonics verwenden:
.section ".text" .align 4 .global my_add_function .type my_add_function,#function my_add_function: ld [%o0], %g4 add %g4, 42, %g1 retl st %g1, [%o0]
Und für eine 32bit PowerPC CPU sieht das ganze noch einmal ganz anders aus:
.text .align 2 .globl my_add_function my_add_function: lwz r2, 0(r3) addi r0, r2, 42 stw r0, 0(r3) blr