Lowlevel
Lowlevel => Softwareentwicklung => Thema gestartet von: timon am 10. December 2011, 09:02
-
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
-
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 (http://Schau dir mal diesen Wikiartikel an: http://www.lowlevel.eu/wiki/Crosscompiler_für_Windows)
-
Bei den Assemblern ist es genauso. Gas ist bei MinGW dabei, für Nasm, Fasm und Yasm gibt es Windowsportierungen.
-
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?
-
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.
-
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.
-
Vielleicht magst du einfach mal hier beginnen: OS-Dev für Einsteiger (http://www.lowlevel.eu/wiki/OS-Dev_f%C3%BCr_Einsteiger) - von dort aus kannst du dich einfach weiterarbeiten.
-
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.
-
Um meinen vielgeschätzten Kollegen Clici McXan (http://www.lowlevel.eu/wiki/Benutzer:XanClic) zu zitieren:
Soll der gcc Intelcode generieren, musst du nur „-masm=intel“ appendizieren!
-
Das Umschalten des Syntax erfolgt über das Assemblerdirektiven
.intel_syntax noprefixund
.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.
-
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.
-
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.
-
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.
-
Naja du hast recht. Ich hab unter MinGW noch nichts gescheites Compiliert bekommen. Meinen Clang hab ich mir unter Linux gebaut.
-
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.
-
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.
-
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).
-
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.
-
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? ;)
-
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.
-
"ziemlich sicher" heißt, dass du es nicht weißt. Und damit auch nicht, ob VBox oder dein Code schuld ist.
-
"ziemlich sicher" heißt, dass du es nicht weißt. Und damit auch nicht, ob VBox oder dein Code schuld ist.
Warum läuft der Code dann überall anders?! Zumal ich soweit war, dass VBox Probleme mit "push gs" hatte, sobald die Instruktion auskommentiert war, lief der Code. Weiter habe ich nicht geguckt, da VBox auch sonst mehr Probleme macht als alles andere.
-
Wenn VBox Probleme mit "push gs" hatte, klingt das eher nach einem komplexeren Problem in deinem Code. Schließlich funktionieren fast alle anderen x86/x86_64 OS in VBox (einzig tyndur brauchte ein "nodma"), die Wahrscheinlichkeit ist daher ziemlich gering, dass es an VBox liegt.
Ich hatte mit VBox trotz umfangreicher Nutzung nie Probleme (hab sogar neulich mit nem Server in VBox auf einem Rechner über PXE Ubuntu installiert) und kann es daher auch empfehlen. Zum Debuggen ist VBox natürlich nicht das Gelbe vom Ei, aber das ist ja klar.
@stultus: Ich blieb damals unter Windows aus zwei Gründen: Zum einen ist 90% meiner restlichen Software Windows-spezifisch, bei einem Großteil davon handelt es sich um Spiele, die unter wine nicht vernünftig laufen. Zum anderen gab (und gibt) es keine gute IDE für FreeBASIC unter Linux. Wobei bei mir jetzt Geany als Notlösung herhält.
-
Bugs in der Virtualisierungssoftware sind nie völlig ausgeschlossen (die werden halt hauptsächlich mit Windows und Linux getestet, und wenn man diese ausgetretenen Pfade verlässt, kommt man in weniger gut getestete Codepfade). Aber wenn man nicht ganz genau sagen kann, woran es liegt und warum die Virtualisierungssoftware das nicht richtig macht, dann würde ich immer auf einen Bug im Kernel tippen.
-
Zum anderen gab (und gibt) es keine gute IDE für FreeBASIC unter Linux. Wobei bei mir jetzt Geany als Notlösung herhält.
Was muss den eine Gute IDE können, so was wie FBEdit? Ich hab mit der Kombination FreeBasic und Geany unter Linux eigentlich keinen Probleme. Eventuell musst du Autovervollständigungsbeschreibungen FreeBasic-Configurationsdatei ändern, aber sonst.
-
ne gute IDE braucht vi und bash ;D
-
Was muss den eine Gute IDE können, so was wie FBEdit? Ich hab mit der Kombination FreeBasic und Geany unter Linux eigentlich keinen Probleme. Eventuell musst du Autovervollständigungsbeschreibungen FreeBasic-Configurationsdatei ändern, aber sonst.
Naja, Geany geht, ich fühle mich halt einfach nicht wohl damit. Ich bevorzuge eigentlich FBIde aber unter wine macht das irgendwie keinen Spaß. Es gab vor einiger Zeit ein vielversprechendes IDE-Projekt mit Linux-Port, scheint aber nicht mehr weiterentwickelt zu werden.
Und jetzt genug OT ;)