Eignet sich der Gnu Assembler für die Betriebssystemprogrammierung?

Hallo,

die meisten Tutorials zum Thema Betriebssystemprogrammierung/Kernelentwicklung/Bootloaderentwicklung verwenden den Assembler NASM, der ja die Intel-Syntax verwendet.

Wenn man sich aber den Sourcecode von Projekten ansieht, die Lowlevel-Zeugs machen (z. B. Grub), dann findet man da meist Assemblercode für den Gnu Assembler.

Daher wollte ich nachfragen: wenn man mal davon absieht, dass der Gnu Assembler nur Object-Dateien (und keine binary-Dateien wie der NASM) erstellt und man am Ende umständlich den Code mit objcopy extrahieren muss, was ist dann der Vortel von as?

Beschäftigt hier sich denn keiner mit Assembler?

Vielleicht die Leute vom PrettyOs-Projekt?

aaaaaaaaaaaaaaaaaaaaaaaab schrieb:

Hallo,

die meisten Tutorials zum Thema Betriebssystemprogrammierung/Kernelentwicklung/Bootloaderentwicklung verwenden den Assembler NASM, der ja die Intel-Syntax verwendet.

Wenn man sich aber den Sourcecode von Projekten ansieht, die Lowlevel-Zeugs machen (z. B. Grub), dann findet man da meist Assemblercode für den Gnu Assembler.

Daher wollte ich nachfragen: wenn man mal davon absieht, dass der Gnu Assembler nur Object-Dateien (und keine binary-Dateien wie der NASM) erstellt und man am Ende umständlich den Code mit objcopy extrahieren muss, was ist dann der Vortel von as?

gas ist einfach schrecklich zum anschauen, deswegen nimmt dann die große mehrheit doch nasm.
gas nimmt man, wenn man ihn nehmen muss. eben für inline asm.

Und das ist eben nicht richtig. Alle Projekte aus diesem Bereich, die irgendwas mit Assembler brauchen (z. B. Bootloader wie GRUB/GRUB2), die ich bisher gesehen habe, nutzten den Gnu Assembler (und zwar nicht nur für Inline-Assembling).

Ich weiß nicht warum, weil die Syntax, die der Gnu Assembler verwendet, ist wirklich nicht so gut zu lesen, viel zu viele $ und % (vorallem auf deutschen Tastaturen ärgerlich, weil man immer Shift drücken muss, wenn man das tippen will).

Verstehe ich übrigens nicht, warum man den Gnu Assembler so auf den gcc eingestellt hat.

Wenn man sich mal anschaut, welche Pseudo-Ops der unterstützt, dann sind das alles Pseudo-Ops, die der gcc braucht. Und es wäre nicht allzu schwierig gewesen, einen Schalter einzubauen, der binary-Code ausgibt.

Die Erklärung ist einfach, der GNU Assembler funktioniert auch noch auf anderen Rechnerarchitekturen*, NASM dagegen nur auf x86/x64.

* Hat dafür Backends oder wie auch immer die Teile heißen.

Crossplattform schrieb:

Die Erklärung ist einfach, der GNU Assembler funktioniert auch noch auf anderen Rechnerarchitekturen*, NASM dagegen nur auf x86/x64.

* Hat dafür Backends oder wie auch immer die Teile heißen.

Ich denk, du meinst, NASM funktioniert nur für x86/x86_64

Aber das ist eingentlich auch kein Argument, viele Prozessoren bringen ihre eigenen Dev-Tools mit, bzw. es gibt eigene Dev-Tools.

So ein Assembler ist relativ einfach zu programmieren, weil die Befehlsreferenzen eher übersichtlich sind.

Soweit ich weiß, gibt es z.B. für ARM eigene Assembler, die die ARM-interne Befehlsreferenz unterstützten.

aaaaaaaaaaaaaaaaaaaaaaaab schrieb:

Aber das ist eingentlich auch kein Argument,

Dann glaub halt an den Weihnachtsmann.

Crossplattform schrieb:

aaaaaaaaaaaaaaaaaaaaaaaab schrieb:

Aber das ist eingentlich auch kein Argument,

Dann glaub halt an den Weihnachtsmann.

Da bleibt mir anscheinend auch nix anderes übrig - ich kann keine Argumente finden, warum man den Gnu Assembler verwenden sollte.

aaaaaaaaaaaaaaaaaaaaaaaab schrieb:

Und das ist eben nicht richtig. Alle Projekte aus diesem Bereich, die irgendwas mit Assembler brauchen (z. B. Bootloader wie GRUB/GRUB2), die ich bisher gesehen habe, nutzten den Gnu Assembler (und zwar nicht nur für Inline-Assembling).

du hast dich im ersten posting gewundert, warum die tuts fast nie gas verwenden.
und den grund hab ich dir genannt.

mag schon sein dass grub oder wer auch immer das verwendet, ist aber trotzdem kein grund dass ich gas in irgendeiner weise schöner finde.
deswegen würde auch ich zu nasm greifen, wenn ich ein tut schreiben würde.

hfghghf schrieb:

du hast dich im ersten posting gewundert, warum die tuts fast nie gas verwenden.
und den grund hab ich dir genannt.

mag schon sein dass grub oder wer auch immer das verwendet, ist aber trotzdem kein grund dass ich gas in irgendeiner weise schöner finde.
deswegen würde auch ich zu nasm greifen, wenn ich ein tut schreiben würde.

Es geht in diesem Thread nicht um Tutorials, sondern um die Frage, warum so viele Projekte den Gnu Assembler verwenden, obwohl dieser keine Vorteile (eher sogar Nachteile) für die Bootloaderentwicklung bringt.

aaaaaaaaaaaaaaaaaaaaaaaab schrieb:

Crossplattform schrieb:

aaaaaaaaaaaaaaaaaaaaaaaab schrieb:

Aber das ist eingentlich auch kein Argument,

Dann glaub halt an den Weihnachtsmann.

Da bleibt mir anscheinend auch nix anderes übrig - ich kann keine Argumente finden, warum man den Gnu Assembler verwenden sollte.

Du stellst die falschen Fragen.

Du hättest fragen sollen, warum GAS die AT&T Syntax verwendet und dann hättest du folgende Antwort erhalten:

" The AT&T syntax is the standard on Unix-like systems but some assemblers use the Intel syntax, or can, like GAS itself, accept both."
http://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax

http://stackoverflow.com/questions/4193827/questions-about-att-x86-syntax-design

Diese Syntax ist der Standard auf Unix-like Systemen?

Seit wann ist die Syntax irgendeiner Assemblersprache an ein Betriebssystem gebunden?

Linux ist es egal, ob das Endprogramm in C, Assembler (At&T-Syntax) oder Assembler (Intel-Syntax) geschrieben wurde. Kompiliert ist kompiliert, bzw. assembliert ist assembliert.

aaaaaaaaaaaaaaaaaaaaaaaab schrieb:

Diese Syntax ist der Standard auf Unix-like Systemen?

Seit wann ist die Syntax irgendeiner Assemblersprache an ein Betriebssystem gebunden?

Linux ist es egal, ob das Endprogramm in C, Assembler (At&T-Syntax) oder Assembler (Intel-Syntax) geschrieben wurde. Kompiliert ist kompiliert, bzw. assembliert ist assembliert.

Bist du ein Troll oder unfähig nachzudenken?

1. Unix ist von AT&T, die haben auch den AT&T Standard für Assembler erfunden.
2. Intel spielte damals als Unix groß war keine Rolle, es gab dutzende anderer Systeme auf denen Unix lief.
3. Da die AT&T Syntax ein Standard auf Unix Systeme war und das GNU System dafür geeignet sein soll, ein Unix Sytem zu ersetzen, war die Wahl für die AT&T Syntax für GAS nur logisch.
4. Linux ist nicht Unix.

Verbreitung schrieb:

Bist du ein Troll oder unfähig nachzudenken?

1. Unix ist von AT&T, die haben auch den AT&T Standard für Assembler erfunden.
2. Intel spielte damals als Unix groß war keine Rolle, es gab dutzende anderer Systeme auf denen Unix lief.
3. Da die AT&T Syntax ein Standard auf Unix Systeme war und das GNU System dafür geeignet sein soll, ein Unix Sytem zu ersetzen, war die Wahl für die AT&T Syntax für GAS nur logisch.
4. Linux ist nicht Unix.

1. Es gibt keinen "Assembler Standard". Warum glaubst du sonst, dass alle Assembler ihr eigenes Süppchen kochen, und eigene Direktiven und Syntaxabweichungen einbauen?
Es gibt x-Assembler, alle haben Syntaxabweichungen, alle unterscheiden sich, sind vollständig inkompatibel.
Und die x86-Befehle wie "mov" usw. sind Teil der x86-Prozessorbefehlsstandards.

3. Ich finde die Wahl nicht logisch. "Gnu System" ist schließlich nicht Unix.

4. Eben. Wenn die AT&T-Syntax "Standard" auf Unix war, muss man das ja nicht auf Linux übertragen, weil "Linux ist nicht Unix".

Du scheinst zu glauben, dass die Syntax einer Programmiersprache (in diesem Fall eine Assemblersprache) fest mit einem Betriebssystem verknüpft ist.
Das ist nicht richtig, wenn ich ein Programm für den Gnu Assembler schreibe, und dann das gleiche Programm in NASM-Syntax, so ist das Kompilat, d.h. der Assembler-output, derselbe. Daher ist es eigentlich egal, ob du den Gnu Assembler nutzt oder den NASM. Die beiden Unterscheiden sich lediglich in der Syntax.
Ebenso ist die Syntax der Assemblersprache selbst unabhängig vom Befehlsstandard:
mov $0, %eax /* AT&T-Syntax */
und
mov eax, 0 /* Intel-Syntax
das ist derselbe Code.

hustbaer

"It is the standard syntax" heisst nicht dass es irgendwo standardisiert wäre. Oder vorgeschrieben.
Vielleicht solltest du Englisch lernen.

Oder aufhören hier blöd rumzutrollen.

aaaaaaaaaaaaaaaaaaaaaaaab schrieb:

1. Es gibt keinen "Assembler Standard". Warum glaubst du sonst, dass alle Assembler ihr eigenes Süppchen kochen, und eigene Direktiven und Syntaxabweichungen einbauen?

Standard != Norm

3. Ich finde die Wahl nicht logisch. "Gnu System" ist schließlich nicht Unix.

ReactOS soll ein freier Ersatz für Windows werden.

Intelligenzfrage an dich:
Macht es nun Sinn, für ReactOS als Kommandozeilenshell die Bash zu verwenden oder zur command.com Shell kompatibel zu bleiben?

4. Eben. Wenn die AT&T-Syntax "Standard" auf Unix war, muss man das ja nicht auf Linux übertragen, weil "Linux ist nicht Unix".

Nur weil GNU den Linux Kernel als Kernel einsetzt bedeutet das nicht, dass sich durch den Einsatz des Linux Kernels etwas an der ursprünglichen Ausrichtung des GNU Systems ändert.

Du scheinst zu glauben, dass die Syntax einer Programmiersprache (in diesem Fall eine Assemblersprache) fest mit einem Betriebssystem verknüpft ist.

Nö, aber ich bin Intelligent genug zu erkennen, dass ich zur bestehenden Syntax des Vorbildsystems kompatibel bleiben muss, wenn die Leute ihren Quellcode auf meinem System mit meinem Assembler weiterhin in Masschinencode umwandeln können sollen.

Wenn ich nämlich einen Ersatz für ein OS schreiben würde, dann wäre meine Aufgabe nicht auch noch eine neue Programmiersprache zu erfinden.

Verbreitung schrieb:

Nö, aber ich bin Intelligent genug zu erkennen, dass ich zur bestehenden Syntax des Vorbildsystems kompatibel bleiben muss, wenn die Leute ihren Quellcode auf meinem System mit meinem Assembler weiterhin in Masschinencode umwandeln können sollen.

Wenn ich nämlich einen Ersatz für ein OS schreiben würde, dann wäre meine Aufgabe nicht auch noch eine neue Programmiersprache zu erfinden.

Es gibt Assembler, die unterstützen beide Syntaxen, sowohl die Intel-NASM-Syntax als auch die At&T-Gnu Assembler-Syntax, nämlich YASM.

Man könnte den Gnu Assembler durch diesen ersetzen. Dadurch wäre gewährleistet, dass sich auch noch ältere Projekte kompilieren lassen, neuere Projekte könnte aber ihren Quellcode nun in der Intel-Syntax schreiben.

Um nochmal auf die Ausgangsfrage zurückzukommen, warum so viele Projekte gas benutzen und nicht nasm:

Du erwähnst als Beispiel nur GRUB , und dieses Projekt startete im Jahr 1995 (Quelle: http://www.gnu.org/software/grub/manual/html_node/History.html). nasm hingegen wurde erst im Jahr 1996 veröffentlicht. gas war damals schon einige Jahre alt (Laut den Copyright-Vermerken für die Anleitung zu gas auf http://tigcc.ticalc.org/doc/gnuasm.html#history gehe ich von 1988 aus). Vermutlich hat der GRUB -Entwickler damals einfach den Assembler verwendet, der ihm zur Verfügung stand, und später sah man keinen Grund, nochmal zu wechseln.

Ganz allgemein darf man nicht vergessen, dass das Internet in den Neunzigern noch nicht so verbreitet war wie heute. Viele hatten überhaupt keinen Zugang, und die Bandbreite war oftmals noch so beschränkt, dass man nicht mal eben so irgendeine Software herunterladen konnte. In vielen Fällen wird man das benutzt haben, was man schon auf irgendwelchen Datenträgern da gehabt hat.

Ok, diese Begründung scheint mir auf jeden Fall einleuchtend.

Aber dem Gnu Assembler fehlen halt meiner Meinung nach wichtige Direktiven und Funktionen, wie z. B.:
1. ein Schalter, mit dem es möglich ist, pure Binary-Dateien auszugeben. In NASM: -f bin
2. NASM unterstützt die times Direktive, mit der es möglich ist, zur Assemblerlaufzeit ein Programm auf eine bestimmte Größe aufzufüllen. Wenn man beispielsweise einen Bootloader entwickelt, dann muss man immer bis auf 510 bytes auffüllen (byte 511 und byte 512 müssen ja bekanntlich einen bestimmten Wert haben, damit das BIOS den Bootloader als Bootloader erkennt). So eine Direktive konnte ich auch nach längerer Suche nicht finden.
3. zu viele unnötige Sonderzeichen, die das Programmieren verlangsamen
usw.

Stattdessen hat der Gnu Assembler unnötige Direktiven, wie beispielsweise .file , mit der kann den Dateinamen der Quelldatei angeben. Wo der Assembler das braucht, bzw. überhaupt verarbeitet, ist mir schleierhaft. Überaus unnötig! Solche Funktionen blähen ein Programm (und den Assembler auch - denn .file muss ja irgendwo geparst werden)nur auf.