Autor Thema: Alternativen zu Assembler und C/C++?  (Gelesen 22090 mal)

eldrige

  • Beiträge: 9
    • Profil anzeigen
Gespeichert
« am: 31. January 2007, 16:46 »
Hallo Zusammen,

Zuerst einmal muss ich Euch für die grossartige Arbeit gratulieren. Vor etwa 5 Jahren konnte ich nur ein einziges Deutsches Tutorial zu diesem Thema finden, in der Zwischenzeit ist aber schon diese Seite entstanden wo man wirklich die letzte Informationen finden kann, die man brauchen könnte!

Nun zu meiner Frage. Ich weiss, dass sie einige hier (wenn nicht alle) etwas ergärn wird, aber ich muss es einfach mal versuchen: Gibt es wirklich keine alternativen zu Assembler und C/C++? Kann man ein OS nicht mit Basic programmieren? Ich denke schlussendlich ist es egal was man für eine Sprache nimmt, wichtig ist nur, dass man keine Windows/Linux Systemspezyfische API verwendet, sondern reine Prozessor befehle, die dann auf jedem Rechner ausgeführt werden können, oder?

PS: Oder besser gefragt, was kann man sonst für die OS Programmierung verwenden ausser ASM & C/C++?

Gruss und Danke im Voraus.
eldrige

MNemo

  • Beiträge: 547
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 31. January 2007, 17:19 »
Gibt es wirklich keine alternativen zu Assembler und C/C++?
Wer hat das den behauptet? Natürlich gibt es Alternativen.

Ich denke schlussendlich ist es egal was man für eine Sprache nimmt, wichtig ist nur, dass man keine Windows/Linux Systemspezyfische API verwendet, sondern reine Prozessor befehle, die dann auf jedem Rechner ausgeführt werden können, oder?
Genau.

Oder besser gefragt, was kann man sonst für die OS Programmierung verwenden ausser ASM & C/C++?
Hab schon öfters gelesen, das Pascal mindestens genauso gut für Kernel-Pragrammierung geeignet sein soll wie C.

„Wichtig ist nicht, besser zu sein als alle anderen. Wichtig ist, besser zu sein als du gestern warst!“

eldrige

  • Beiträge: 9
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 31. January 2007, 17:21 »
Danke :)

und ausser Pascal, was kann man sonst noch verwenden?

Gruss

Korona

  • Beiträge: 94
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 31. January 2007, 17:55 »
Du kannst dein OS in jeder Sprache programmieren, sogar in Java oder C#, wenn du die entsprechende Laufzeitumgebung hast. Allerdings wirst du Sachen wie direkte Speicher und Registerzugriffe benötigen, und dass ist in manchen Sprachen höchstens über Umwege erreichbar.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 01. February 2007, 00:11 »
Verwendbar sollte eigentlich jede Sprache sein, für die es einen Compiler gibt, der Code für i386 erzeugt - die Frage ist nur immer, mit welchem Aufwand. Sehr hilfreich wäre es, wenn die Sprache Inline-Assembler unterstützt, denn ganz ohne geht es eben doch nicht.

Ich wüßte aber jetzt keinen hier, der eine andere Sprache als Assembler, C/C++ oder Pascal benutzt. Das dürften einfach die naheliegendsten Alternativen sein. Wenn du dich für was anderes entscheidest, mußt du dich auch bewußt sein, daß du ein Stück weit etwas machst, was noch kein anderer hier gemacht hat und wo du tendenziell eher alleinegelassen bist, wenn es Probleme gibt. (Andererseits, das sollte ich vielleicht auch nicht verschweigen, war das gerade der Grund, warum ich einen Kernel in Pascal angefangen habe: In C habe ich mich zu viel beim planlosen Kopieren von fremdem Code erwischt und in exotischere Sprachen muß man Beispielcode zumindest übersetzen, wobei man dann wenigstens ansatzweise ein Verständnis gewinnt ;))
« Letzte Änderung: 01. February 2007, 00:14 von taljeth »
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

eldrige

  • Beiträge: 9
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 01. February 2007, 10:01 »
Vielen Dank taljeth

Ich bin gestern zufällig auf eine andere Sprache gekommen (die Euch eventuelle bekannt ist). Es handelt sich um Weiterentwicklung von QBasic und die heist jetzt FreeBasic http://freebasic.de/ .
Die Sprache macht einen sehr netten Eindruck! Wird Compiliert, unterstützt InLine Assembler und und und.
Nun ich sehe langsam ein was Du meinst. Wenn man der 'Erste' ist, dann geht es sehr schwer, weil man keinen nach Erfahrung fragen kann. Für mich stellt sich jetzt die Frage, wo und was muss ich fragen, weil, die die mit FreeBasic programmieren, die machen bestimmt kein OS und die die OS programmieren, haben bestimmt mit FreeBasic nix zu tun!

Um aus dieser etwas schwirigen Lage heraus zu kommen, werde ich hier einfach mal folgendes Fragen:

Welche Sprachfunktionalitäten braucht man ausser InLine Assembler? Braucht man irgendwelche Interupts Funktionen (sind die Prozessorseitig gegeben oder habe ich das mit DOS verwechselt)?

Noch vielleicht eine kleine Frage: Wenn ich ein grafisches OS erstellen möchte, dann muss ich also grafische Prozessoranweisungen verwenden (es geht natürlich nicht mehr über WIN API, DirectX oder OpenGL). Nun welche Möglichkeiten hat man da? Ich stelle mir vor, dass Prozessor nur einen einzigen Befehl zur Verfügung stellt und zwar das Zeichnen eines Punktes. Die restliche Formen müsste man dann selber programmieren bzw. eigene OS Funktionen dafür schreiben, oder? Oder werden grafische Objekte gezeichnet indem man direkt in den Grafischen Speicher die Bits setzt?

Hmmm sorry falls es etwas zu viel auf einmal ist, aber es sind denke ich nur zwei Fragen. Danke schon mal im Voraus.

eldi

Termite

  • Beiträge: 239
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 01. February 2007, 11:05 »
Moin

Grafische Prozessoranweisungen? was ist das?

dein prozessor stellt dir direckt keine befehle bereit mit denen du was zeichnen kannst (ala punkt x,y in farbe f). das must du schon selber mit der hardware und dem speicherbereich ausmachen, den die grafikkarte verwendet. (entsprechenden wert an die entsprechende Addresse schreiben)

Sprich deine Programiersprache muss direckte Speicheraddresierung unterstützen.

Wird ein Intterupt ausgelöst, unterrbricht der Prozessor dein Programm, lädt einen bestimmten speicherbereich, und springt dann an diese addresse, um die entsprechende Interruptservicerotine auszuführen. Was must du somit tun, den Funktionspointer an die entsprechende stelle im speicher hinterlegen. Und ggf dafür sorge tragen, das die Funktion auch die Anforderungen einer Intteruptservicerotine erfüllt. z.B. IRET anstelle von ret am ende, damit der prozessor weis, das der Interrupt zuende ist.


Also möglichkeit für Asm bzw Inlineassembler ist notwendig
Direkte speicheraddresierung
Erstellen Obj dateien, die hinterher passend verlinkt werden können.

@Korona Was soll das für ein OS sein, das erst mal eine Laufzeitumgebung benötigt? da ist doch die Laufzeitumgebung doch schon fast das OS selbst. zumindest bei java. bzw die laufzeitumgebung von sun selber braucht son wieder ein OS.

Bei java könnte ich mir vorstellen, nur den Syntax zu verwenden. ( laufzeitumgebung überbord werf ) den java BinaryCode dann in Mashinen code übersetzen und versuchen zum laufen zu bringen. Weiter wird das ansprechen von speicher nicht möglich sein, da der syntax das garnicht hergibt. sprich man muss dann sowas von ausen durch den linker machen. ( Statisches Classen element VideoBuffer[65536] wird an addresse 0xA0000 gelinkt) Inlineassembler?

Mir ist bekannt, das java auch im embeded bereich eingesetzt wird, es java prozessoren gibt (Java erweiterungen für arm cors). nur hat das weniger was mit dem java zu tun, das ihr kennt.

gruss

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 01. February 2007, 11:27 »
Noch vielleicht eine kleine Frage: Wenn ich ein grafisches OS erstellen möchte, dann muss ich also grafische Prozessoranweisungen verwenden (es geht natürlich nicht mehr über WIN API, DirectX oder OpenGL).
Ich sehe, du hast noch viel zu lernen. ;) Macht nichts, jeder fängt klein an. Aber mein Tip an dich wäre, Grafik für das nächste Jahr mal komplett zu vergessen. Es gibt viel anderes, was stehen sollte, bevor es überhaupt Sinn macht, sich damit zu beschäftigen. Wenn du mit deinem exotischen Compiler ein "Hello world" auf dem Bildschirm hast, hast du vermutlich schon ein ganzes Stück geleistet.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

eldrige

  • Beiträge: 9
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 01. February 2007, 15:05 »
@Termite
Tut mir leid, dass ich mit mich LowLevel Programmierung zu wenig auskenne. Ich bin Profi-Programmierer, verwende aber in der letzten Jahren ausschliesslich DOTNET und VBA (MS Access, MS Excel) und dort sind die Funktionen und Klassen einfach wie eine BlackBox. Man weisst nicht was drin steckt und man interessiert sich auch nichtdafür. Hauptsache man kommt schnell zum Ziel und es funktioniert.
Jetzt wo ich mich mit LowLevel Programmierung befasse, sehe ich dass es ganz andere Welt ist und das mein Wissen über DOTNET & Co wenig nützt!

Ich kann also etwas Zeichnen (z.B. einen Punkt) indem ich direkt die Bits in der Videomemory setze. Gibt es dafür hier irgendwo ein kleines Tut, der das erklärt? Danke.

Im FreeBasic Forum habe ich bereits nachgefragt, ob die Sprache direkte Speicheradressierung unterstützt. Ich habe das gefühl, dass man sich darunter schwierig etwas vorstellen kann. Ist das einfache Pointeradresierung? Oder kann man diese Adressierung auch über Assembler machen (weil FreeBasic unterstützt ausch InLine Assembler, dann könnte ich es auf die Art und Weise machen).

@taljeth
Falls man mit FreeBasic auch zum eigenen OS kommen kann, dann denke ich wird es viel schneller sein, als mit C/C++ :) .
Haste die Homepage von FreeBasic angeschaut? Meinst Du man könnte damit wirklich ein OS coden?

Gruss

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 01. February 2007, 15:35 »
Hallo,

Ausgaben auf dem Bildschirm kannst du prinzipiell auf zwei Weisen machen:
(a) du programmierst die Register und schreibst in den Grafikspeicher
(b) du rufst passende Interrupt-Routinen vom BIOS (bzw. bei EGA/VGA vom Grafikbios) auf (ich glaub int 10h is das)

(a) heißt, eigenen Grafiktreiber programmieren und sich mit der Hardware auseinander setzen.
(b) heißt, sich auf VGA (oder VESA) beschränken und Geschwindigkeitseinbußen in Kauf nehmen.

Die Speicheradressierung ist auch so 'ne Sache, weil du ja im Real Mode und im Protected Mode die gesamte Speicherverwaltung komplett neumachen musst. Inwiefern Freebasic dafür geeignet ist, weiß ich nicht, aber du bist im Protected Mode auch bestimmten Beschränkungen unterworfen (keine privilegierten Befehle außerhalb des Kernels, verschiedene Speicherbereiche...). Wenn Inline-Assembler unterstützt wird (oder du sogar eine Assembler-Bibliothek einbinden kannst), sollte es aber prinzipiell möglich sein. Die Frage ist nur, wie weit du den Aufwand treiben möchtest - wenn es am Ende darauf hinauslaufen würde, 80% in Assembler schreiben zu müssen, würde ich nocheinmal darüber nachdenken.

Interrupts werden dir vom BIOS gegeben, solange du dich im Realmode befindest. Danach musst du alles selbst machen. DOS stellt dir aber auch Interrupts zur Verfügung (z.B. int 21h, der DOS-Funktionsverteiler), die du ohne DOS nicht nutzen kannst.

Aber bedenke eins: Für Assembler brauchst du keine Unterstützung, für C auch nicht. Aber du wirst wahrscheinlich nicht umhin kommen, für dein Freebasic eine Laufzeitbibliothek zu programmieren. Sonst funktioniert ja kein PRINT (weil kein Bildschirm vorhanden ist), kein DIM (weil ja die Speicherverwaltung für Variablen fehlt) usw... also die elementarsten Sachen fehlen.

Gruß,
Sebastian

eldrige

  • Beiträge: 9
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 01. February 2007, 16:01 »
Zitat
Aber bedenke eins: Für Assembler brauchst du keine Unterstützung, für C auch nicht. Aber du wirst wahrscheinlich nicht umhin kommen, für dein Freebasic eine Laufzeitbibliothek zu programmieren. Sonst funktioniert ja kein PRINT (weil kein Bildschirm vorhanden ist), kein DIM (weil ja die Speicherverwaltung für Variablen fehlt) usw... also die elementarsten Sachen fehlen.

 :-(

Danke trotzdem.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 01. February 2007, 16:35 »
Ist der Compiler selbst in FreeBASIC geschrieben? Das wäre ein klares Zeichen, daß damit alles machbar ist.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Termite

  • Beiträge: 239
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 01. February 2007, 16:54 »
Nabend

In c/c++ darf man auch nicht einfach so alles verwenden. sonst knalltz auch. Includs von bibliotheken gehen ja auch nicht, da di lib nicht portiert ist. new / delete, alloc malloc, realloc das gleiche.

Solang kein funktionen aufgerufen werden,  oder Objecte verwendet werden die man nicht selber geschrieben hat sollte alles in ordnung sein. Nur Basic könnte so böse sein, Sachen wie Print einfach immer mit anbieten zu wollen, ohne vorher einen Include, import, use,... zu machen.

gruss

eldrige

  • Beiträge: 9
    • Profil anzeigen
Gespeichert
« Antwort #13 am: 01. February 2007, 17:06 »
Könnte jemand von Euch schnell einen Blick auf FreeBasic Homepage werfen http://freebasic.de/index.php ? Danke. 
Falls es gar nicht für ein OS geeignet ist, dann könnte ich mir viel Zeit sparen. Selber werde ich es erst zu spät merken, dass es vielleicht nicht geht.

Zu finden ist unter anderem auch folgendes:

- FreeBASIC (kurz FB) ist ein recht junges Projekt.
- Es ist ein Basic-Compiler, der auf Windows und Linux und auch DOS verwendbar ist.
- FreeBASIC ist kompatibel zur Syntax von Microsoft's QuickBASIC das gegen Ende der 80'er Jahre entwickelt wurde. Das ist auch der Grund, warum man Free- und QuickBASIC-Foren meist zusammen findet.
-Er ist für jedermann frei erhältlich, weil es ein Open-Source-Projekt ist. Das heißt Du kannst ihn kostenlos herunterladen und benutzen.
-Programme, die damit kompiliert werden, laufen ohne Zusätze wie Runtime-Interpreter.
-Und ob Du Deine Programme dann frei weitergibst, oder als Shareware oder gar als Nichtfreie Software anbietest, ist Deine freie Entscheidung.

Eine vollständige Liste findet man auf der Englischen Seite unter: http://www.freebasic.net/index.php/about?section=features

PS: Obwohl, ich habe dort schon Leute angetroffen, die damit ein OS proggen (siehe http://mao.freebasic.de/exorc/blog/index.php )
Von dem her würde ich auch meinen, dass damit alles möglich wäre.

Gruss

JensFZ

  • Beiträge: 96
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 02. February 2007, 08:51 »
Hiho

Also ich habe mir den mal angeschaut und bin mir nicht ganz sicher. Wie ich gesehen habe, kann man den compiler sagen, dass man keine Standartbibliotheken haben will und dass er es auch nicht eigenständig linken soll.

dass DIM nicht gehen soll, wie es Svenska gesagt hat, kann ich mir nicht vorstellen. ein "DIM test as integer" ist im grunde genommen nichts anderes als "int test" in C/C++ und das funzt ja auch. Wo Svenska aber recht hat ist, dass man sowas wie Print nicht nutzen kann, da es an eine Standartbibliothek gebunden ist.
Wie ich gesehen habe, kann FB auch mit Pointern umgehen, also anders gesagt kann FB auch direkt mit Speicheradressen arbeiten. Von daher kann man schonmal etwas rumspielen. sollte etwas nicht möglich sein, hast du ja immernoch inline ASM und kannst zur not nen c/c++ modul noch backen, das du dort mit integrierst.

Ciao JensFZ
 

eldrige

  • Beiträge: 9
    • Profil anzeigen
Gespeichert
« Antwort #15 am: 05. February 2007, 09:19 »
Vielen Dank JensFZ,

In der Zwischenzeit habe ich dort einiges betrefend FreeBasic erfahren. Man ist noch immer gespalten in der Meinung, ob man mit FreeBasic ein OS coden kann oder nicht, weil sehr viele Fake OS damit schon gecodet wurden.
Auch über Sinn und Zweck einer neuen OS Entwicklung wurde geschrieben (was hier auch sicher öfters der Fall sein wird). Meiner Meinung nach hängt die Effektivität eines OS grössten Teils davon welche Entwicklungstools man damit auch noch ausliefert. Das heisst wenn ich für ein neues OS nur in Assebmler coden kann, wird mich die Lust nach neuem OS schnell vergehen. Wenn aber jemand eine einfache Sprache (etwa BASIC o.ä.) zur Verfügung stellen würde, dann könnte ich mir vorstellen, dass ich eine oder andere Applikation, die ich bereits in Windows programmiert habe, auch dort portiere. Wenn von mehreren Milionen Programmierer nur jeder 10te so etwas macht, dann kann auch der 'kleinste' OS sehr schnell bekannt werden, weil es dafür einfach viele Applikationen gibt!

So, Frage ist nun, soll man ein OS coden, oder soll man besser zuerst eine einfache Sprache entwickeln, mit der man dann ein OS coden kann und folglich auch alle Applikationen für das OS? Was die Grafik zum Beispiel betrifft, da müsste man nur ein Befehl für das Zeichnen eines Punktes zur Verfügung stellen und schon konnte man mit der neuen Sprache alle mögliche Funktionen für das Zeichnen von Kreis, Rechteck usw. erstellen, folglich wäre ein Grafisches OS in wenigen Tagen fertig, oder?

Warum hat also keiner bisher eine einfache Sprache entwickelt, die nur die Prozessor Befehle verwendet? Alle gängige Sprachen lehnen sich an die Windows oder Linux API Befehle an, was für ein neues OS dann unbrauchbar ist! Dass man noch immer C/C++ zur Verfügung hat nützt, wie wir es sehen, wenig, weil der grösste Teil von diesen Millionen-Programmierer machen doch die NICHT C/C++ Programmierer aus!
 

Gruss

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #16 am: 05. February 2007, 10:08 »
Warum hat also keiner bisher eine einfache Sprache entwickelt, die nur die Prozessor Befehle verwendet? Alle gängige Sprachen lehnen sich an die Windows oder Linux API Befehle an, was für ein neues OS dann unbrauchbar ist!
Jede Sprache verwendet nur Prozessorbefehle. Nur kannst du halt für ein OS im allgemeinen keine Bibliotheken benutzen - das ist ja genau das, was das OS selbst bereitstellen soll, das ist die Definition eines OS. Also ich bin recht froh, daß ich nicht einen Browser mit integriertem Treiber für meine Netzwerkkarte brauche.

Vielleicht willst du in Wirklichkeit gar kein OS schreiben, sondern nur eine Shell für DOS?
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Termite

  • Beiträge: 239
    • Profil anzeigen
Gespeichert
« Antwort #17 am: 05. February 2007, 13:45 »
So, Frage ist nun, soll man ein OS coden, oder soll man besser zuerst eine einfache Sprache entwickeln, mit der man dann ein OS coden kann und folglich auch alle Applikationen für das OS? Was die Grafik zum Beispiel betrifft, da müsste man nur ein Befehl für das Zeichnen eines Punktes zur Verfügung stellen und schon konnte man mit der neuen Sprache alle mögliche Funktionen für das Zeichnen von Kreis, Rechteck usw. erstellen, folglich wäre ein Grafisches OS in wenigen Tagen fertig, oder?

man könnte die applikation sehr schnell auf andere gui systeme von anderen Betriebsytemen portieren, das ja. nur besonders schnell ist das leider nicht. für jden der ca 1Millon pukte muss man eine funktion aufrufen.

Warum hat also keiner bisher eine einfache Sprache entwickelt, die nur die Prozessor Befehle verwendet? Alle gängige Sprachen lehnen sich an die Windows oder Linux API Befehle an, was für ein neues OS dann unbrauchbar ist! Dass man noch immer C/C++ zur Verfügung hat nützt, wie wir es sehen, wenig, weil der grösste Teil von diesen Millionen-Programmierer machen doch die NICHT C/C++ Programmierer aus!
ich versteh hir grad nur banhof.

Prozessor Befehle sind für mich ASM anweisungen wie MOV, ADD, INC, DEC, SUB MUL, CALL RET, JMP,.... oder verstehe ich dich da falsch? Somit ist der Assembler die Programiersprache die die Prozessorbefehle verwendet.

Wiso soll die programiersprache daran angelehnt sein? Eine API stellt neue Funktionen und "neune Befehle" zur verfügung, die der Entwickler verwenden kann, damit er nicht alles selber machen muss. das ich ja auch der grund wieso es Betriebsysteme gibt. Ein Betriebsystem ist eigentlich nichts anderes als eine sammlung von Funktionen, (manche mögen auch befehle dazu sagen) die gewisse wiederkehrende Aufgaben bereits implementiert haben, und somit die Software entwicklung beschleunigen und vereinfachen. (Datei verwaltung, Netzwerkschnitstellen, GUI, Prozesse, Resorcenverwaltung, Interprocesskomunikation,...)

In C/C++ kannst du die zusätzlich zur verfügung gestellten Funktionen verwenden, musst dies aber nicht, du kannst sie auch selber implementieren. Das ist aber in jeder Programiersprache so. In C/C++ passiert das durch Includes, in java durch imports,...

gruss


eldrige

  • Beiträge: 9
    • Profil anzeigen
Gespeichert
« Antwort #18 am: 05. February 2007, 16:25 »
Zitat
ich versteh hir grad nur banhof.

Prozessor Befehle sind für mich ASM anweisungen wie MOV, ADD, INC, DEC, SUB MUL, CALL RET, JMP,.... oder verstehe ich dich da falsch? Somit ist der Assembler die Programiersprache die die Prozessorbefehle verwendet.
Klar und genau das ist für die meisten aktuellen Programmierer das grösste Problem. Du kannst wahrscheinlich jedes Algorithmus in wenigen sekunden in ein Assembler Code umwandeln, ich (und Millionen andere) nicht. Was wir machen können ist das selbe aber in einer Sprache, die uns viel verständlicher aussieht, und die ist in der Regel ein BASIC Dialekt (sei es VB, VBA, VB.NET, FREEBASIC o.ä.).

Ich dachte eben, dass die FreeBasic sprache so etwas ermöglichen könnte, also dass man auf alle Prozessor Befehle zugreiffen kann, aber scheinbar werden beim Compiler noch andere Lib's gelinkt, die dann in eigenem OS nicht 'verstanden' werden (ja klar wenn es die gar nicht gibt). Also ein Basic mit dem man schon ein eigenes OS coden könne wäre sicher sehr interessant für die restliche Programmierer-Welt, die sich mit Assembler nur schwer befreunden können :)

Gruss

Termite

  • Beiträge: 239
    • Profil anzeigen
Gespeichert
« Antwort #19 am: 05. February 2007, 17:55 »
Mit nichten. ich kann zwar ASM, brauch dazu aber meist die docu dazu. viel zu viele befehle, alle HW abhänging, und überal gibts kleine aber gemeine stolpersteine. Big Endian, Litel Endian, ( arm kann beides ) RISC CISC Befehlssätze, .... Aber wozu hat man den die hochsprachen geschaffen? genau deswegen. Komplexe abläufe so einfach wie möglich beschreiben zu können. Es geht ja sogar mitlerweile noch viel weiter, Model Driven Development, OOP, Aber das sollte dir ja bekannt sein.

Was dein Problem ist, das dein compiler standart libs mit einbindet.  Das die in deinem os vorhanden sein müssen stimmt nicht, sie werden ja dazugelinkt. es ist eher so, das die dafür notwendigen DLLs nicht vorhanden sind, bzw auf betriebsytem spezifische sachen zugegriffen wird. in etwa so wie wenn du eine .Net verteilst. Das .Net Framwork muss installiert sein, sonst gehts nicht.

Bei C/C++ kann man das halt ausschalten. In c ist es sogar so, das die sprache an sich nur ihren syntax kennt, und alles was darin geschrieben wird platform unabhängig ist. alle zusätzlichen Funktionen wie z.B. Printf, scannf, ... müssen alle erst über einen Include hinzugefügt werden. Bei c++ machen new und delate eine ausnahme. sie sind Sprachbestandteil, der eine Platformspezifische implementierung benötigt. Aber solang man sie nicht verwendet, braucht man sie auch nicht zu implementieren.

Aber jede sprache hat seine vor und nachteile, und somit seine bereiche in der IT wo sie punkten können. Fortran obwohl es schon sehr alt ist, findet im bereich ströhmungssimulation noch anwendung, und überal da, wo Mathematik im fordergrund steht.



gruss

 

Einloggen