Thema: Welche Compiler

[timon]

Hallo Zusammen
Ich arbeite auf einem Windows System und möchte wissen welche Compiler /Linker/Assembler
ihr mir empfehlen würdet.
Ich kann C und Assembler programmieren und möchte mit diesen beiden Sprachen ein kleines OS schreiben.
Ich habe es bereits einmal versucht und gab das Projekt auf wegen Compiler Errors .

Danke für eure Hilfe

[kevin]

Der übliche Weg unter Windows ist eine MinGW-(Cross-)Toolchain zu nehmen (also gcc als Compiler und binutils für Assembler/Linker) und für die Buildumgebung zusätzlich noch MSYS.

Schau dir mal diesen Wikiartikel an: http://www.lowlevel.eu/wiki/Crosscompiler_für_Windows

[Sannaj]

Bei den Assemblern ist es genauso. Gas ist bei MinGW dabei, für Nasm, Fasm und Yasm gibt es Windowsportierungen.

[timon]

Danke für eure Hilfe
Ich habe den Crosscompiler ausprobiert und er geht.
Eine Frage habe ich noch: Muss ich die
VBE vom Vm86 oder vom Realmode aus initialisieren?

[kevin]

Funktioniert beides.

Ich würde aber empfehlen, am Anfang noch nicht in einen Grafikmodus zu wechseln, weil das das Debugging wesentlich schwieriger macht. Eine Textmodus-Fehlermeldung auf den Bildschirm zu bringen funktioniert fast immer, aber damit das gleiche im Grafikmodus geht, muss wesentlich mehr Code funktionieren. Und wenn es eine Fehlermeldung gibt, dann funktioniert ja meistens eben gerade nicht mehr alles wie es soll.

[timon]

OK das mit dem Grafikmodus probiere ich noch nicht.
Habt ihr eine genauere Anleitung wie das mir dem Cross-Compiler geht? Ich verstehe ihn doch nicht ganz.

[DerHartmut]

Vielleicht magst du einfach mal hier beginnen: OS-Dev für Einsteiger - von dort aus kannst du dich einfach weiterarbeiten.

[Dimension]

Ich will ja ncht unhöflich sein, aber ich habe gute Erfahrungen gemacht mit den inline-Assemblern von GCC (leider AT&T-Syntax) bzw. von MS Visual CPP. Irgendwie kann man beim neuen GCC auch auf Intel-Syntax stellen, aber das muss am Ende des ASM-Abschnitts wieder rückgängig gemacht werden.

[DerHartmut]

Um meinen vielgeschätzten Kollegen Clici McXan zu zitieren:

Soll der gcc Intelcode generieren, musst du nur „-masm=intel“ appendizieren!

[Sannaj]

Das Umschalten des Syntax erfolgt über das Assemblerdirektiven

Code: [Auswählen]

.intel_syntax noprefixund

Code: [Auswählen]

.att_syntax prefoxHierbei bedeutet .intelsyntax das der Intelsyntax benutzt wird und nopräfix, das die Register ohne vorrangestelltes "%" angesprochen werden können. Der Assembler nimmt zu Beginn AT&T Syntax an.
Zu beachten ist, das gcc, diese Option nicht kennt oder irgendwie bearbeitet. (Gcc hat überhaupt keine Ahnung was die Inline Assemblerbefehle bedeuten.) Aus diesem Grund muss der Assembler am Ende des Aufrufs wieder auf das eingestellte Emitdirektiv (normal AT&T-syntax, mit „-masm=intel“ Intelsynatx) umgestellt werden.

[FlashBurn]

Ich weiß nicht ob es schwieriger ist einfach nen Linux in einer VM aufzusetzen und dort den vorhandenen GCC zu nutzen. Kann dafür nur den VMWare-Player empfehlen, einfach die Tools installieren und man kann dann nen Shared-Ordner anlegen, unter Windows coden und unter Linux (in der VM) kompilieren. Bei mir ist das ganze um das 3.5fache schneller.

[Sannaj]

Ich weiß nicht ob es schwieriger ist einfach nen Linux in einer VM aufzusetzen und dort den vorhandenen GCC zu nutzen. Kann dafür nur den VMWare-Player empfehlen, einfach die Tools installieren und man kann dann nen Shared-Ordner anlegen, unter Windows coden und unter Linux (in der VM) kompilieren. Bei mir ist das ganze um das 3.5fache schneller.

Könntest du auch machen. Ist aber mit Abstand lahmer (Compilieren ist harte CPU-Arbeit) und weniger elegant. MinGW funktioniert für das reine Compilieren von Programmen gut, und ist auch nicht als so schwer aufzusetzen, gcc, g++, gccirgentwas, gdb und die Binuits werden unterstützt und laufen ziemlich vernünftigt. msys stellt eine vernünfige Umgebung (Pfade, Shell zu Verfügung). Schwierig wird es natürlich wenn du Python (Mein Remote-control-Shellscript klappt hierbei nicht immer richtig, bei git und fbc aber schon.), oder irgendwelche ausgefallenen Sachen wie iso-maker, usw. brauchst.

[FlashBurn]

Könntest du auch machen. Ist aber mit Abstand lahmer (Compilieren ist harte CPU-Arbeit) und weniger elegant. MinGW funktioniert für das reine Compilieren von Programmen gut, und ist auch nicht als so schwer aufzusetzen, gcc, g++, gccirgentwas, gdb und die Binuits werden unterstützt und laufen ziemlich vernünftigt. msys stellt eine vernünfige Umgebung (Pfade, Shell zu Verfügung).

Eben nicht, es ist bei mir um das 3.5fache schneller! Eben weil unter mingw noch der kanze POSIX-Layer KRams emuliert werden muss und das kostet richtig Zeit. Ich hätte das so auch nicht gedacht, da ich aber den neuen clang unter mingw nicht kompiliert bekommen haben und sowieso schon Linux in einer VM hatte, habe ich das mal ausprobiert und mache es jetzt nur noch so.

Zumal wenn man ne halbwegs aktuelle CPU hat die Hardwareunterstützung für das Virtualisieren bietet, ist der Geschwindigkeitsverlust vernachläßigbar.

[Sannaj]

Naja du hast recht. Ich hab unter MinGW noch nichts gescheites Compiliert bekommen. Meinen Clang hab ich mir unter Linux gebaut.

[Alphaleath]

In der c't 3/12 ist ein sehr gutes Tutorial für eine Portable Eclipse-Umgebung mit dem GCC-Toolchain. Aber trotzdem würde ich für OS-Entwicklung ein Linux nehmen. Das kannst du ja in einer VM laufen lassen oder Parallel zum Win installieren.

[TheThing]

Ich habe früher mein OS auch immer in einer VM kompiliert. Ich fand das früher aber ziemlich eklig die Code-Files in die VM zu kriegen und das Kompilat wieder raus.
Da ich mittlerweile git benutze und auch ein Notebook mit Linux mein eigen nenne geht das jetzt besser
Ich habe mich damals für Linux entschieden da ich dort am wenigstens Aufwand mit der Umgebung hatte (ELF wird unterstützt, ich hab direkt gcc) und ich sowieso Linux mehr mag. Letztendlich ist die Frage nach dem Compiler und dem OS Geschmackssache.
Das mit der Geschwindigkeit bei MinGW stimmt, im Vergleich zum Linux-gcc ist es sehr langsam. Selbst gcc auf meinem P4 mit 2.8 GHz schlägt den MinGW auf meinem Core 2 um Längen. Das hat eben damit zu tun dass gcc eigentlich für eine POSIX-Umgebung ausgelegt ist und unter Windows da jede Menge Kompatibilitätskram dazwischenhängt.
Noch langsamer ist bei mir mingw64, sowohl in der 32- als auch in der 64-Bit Version (ich benutze ein personal build von gcc 4.6.2 mit std::thread-Unterstützung aufgrund eines anderen Projektes von mir). Die erzeugten Programme jedoch sind bei allen drei Varianten bei mir schneller als mit VC++ erzeugte.

Je nach Geschmack kommen in diesem Fall also entweder eine VM mit Linux+gcc oder ein Cross-MinGW infrage. Ich bevorzuge Linux+gcc, aber das ist eine Entscheidung die man selbst treffen muss.
In Sachen Assembler fiel meine Wahl auf nasm. Manche mögen vielleicht schief gucken, weil ich unter die gcc-Familie nasm mische, aber ich kam mit nasm bisher super klar und es war auch der erste den ich je benutzt habe.

[stultus]

Bei der ganzen VM-Diskutiererei (übrigens auch meine präferierte Lösung - msys, mingw und crosscompiler dauert wirklich bis das gescheit läuft), wieso bleibt ihr zum editieren alle unter Windows? Mit halbwegs modernen Maschinen (Von Hardwarevirtualisierung geh ich mal aus, ohne macht das nicht soo den Spaß) ist das an sich kein Problem auch noch die grafische Oberfläche und nen Editor mitzuziehen. Copy&Paste geht dank der Gasterweiterungen unter allen gängigen Emulatoren auch wunderbar.

Als Virtualisierungslösung würde ich übrigens VirtualBox empfehlen, gibts ohne Registrierung, und tut wasses soll ohne zuviel mitzubringen (VMWare ist halt eher für professionelle Anwendung ausgelegt).

[FlashBurn]

Also VBox kann ich gar nicht empfehlen. Denn darin läuft mein OS nicht

Aber der VMWare Player ist eigentlich super, vorallem halt mit den Gasterweiterungen.

[kevin]

Wie wär's einfach mit direkt Linux auf dem Host?

Also VBox kann ich gar nicht empfehlen. Denn darin läuft mein OS nicht

Und welche Seite ist buggy?

[FlashBurn]

Und welche Seite ist buggy?

VBox Denn in allen anderen Emulatoren/VMs und auf richtigen PCs läuft der Code ohne Probleme. Ich weiß sogar ziemlich sicher dass es etwas mit den GS und FS-Registern zu tun hat.