Da der andere Pascal Thread unerträglich lang geworden ist, ein neuer Ansatz. Oft wird behauptet, das Pascal sich nicht für Betriebssysteme eignen würde http://wiki.freepascal.org/Operating_Systems_written_in_FPC Auch ein interessantes Projekt,(kein Betriebssystem aber dicht dran) leider beklagen hier einige das es nur auf PAscal basiert https://ultibo.org/
:
Bearbeitet durch User
Max S. schrieb: > ein neuer Ansatz. Ansatz wozu ? Streiterei, Fanboywerbung ? Nimm einfach die Realität an, dann erspart sich jede Bierzeltdiskussion.
Max S. schrieb: > Oft wird behauptet, das Pascal sich nicht für Betriebssysteme eignen > würde Was nicht alles behauptet wird - es gibt keine Erderwärmung, Trumps Amtseinführung war die grösste Versammlung der Menschheitsgeschichte, und überhaupt ist die Erde eine Scheibe... Schon eines der ersten Betriebssyteme, für die Pascal Microengine, war in Pascal geschrieben, vor undenklichen Zeiten. Georg
Weder Wirths Standard Pascal von 1974, noch Pascal nach ISO-Norm eignen sich zur Implementation eines Betriebssystems auf einer realen Hardware. Der Grund ist einfach, es fehlen in den Sprachstandards Zugriffsmöglichkeiten auf Hardware. Jetzt kann man anfangen zu Pfuschen und was fehlt mit Spezialbibliotheken die z.B. in Assembler geschrieben sind nachrüsten, oder man bohrt die Sprache auf. Hunderte von Pascal-Implementierungen und -Dialekten haben nicht-standardisierte Erweiterungen, mit denen man die notwendigen Zugriffe auf reale Hardware implementieren kann. Wer mag kann sich damit ein Betriebssystem implementieren. Warum man heutzutage ein Betriebssystem in einem Pascal-Dialekt implementiert? Weil man nichts anderes kann oder weil man geistige Onanie betreiben möchte.
Hannes J. schrieb: > Der Grund ist einfach, es fehlen in den Sprachstandards > Zugriffsmöglichkeiten auf Hardware. Ist in C übrigens genauso. Die Konstrukte für den direkten Speicher-Zugriff sind vom Standard nicht erlaubt und funktionieren nur mehr oder weniger zufällig, weil die Compiler das nicht finden und anmäkeln können.
ja.nur in C..nennen sie es..neue Version..in Pascal nennen sie es Gefrickel..aufbohren... An manchen geht einfach vorbei das ALLE Sprachen sich entwickeln..sowohl Basic, Pascal als auch C. Nur das der Standard bei Pascal nicht ISO sondern Borland bzw Delphi bzw FrePascal heißt. Eigentlich gar nicht so schwer
Ich lese übrigens gerade "just for Fun" die Linus Torvalds Biographie.. Auch der Linux Kernel wurde in C und zum nahezu gleichen Teil in Assembler geschrieben...
:
Bearbeitet durch User
In keiner der gängigen Programmiersprachen (darunter aich C und Pascal) lässt sich ein ernst zu nehmendes Betriebssystem (inkl. Bootvorgang, Kontextumschaltung für Multitasking usw.) vollständig implementieren. Ein paar Teile müssen immer noch in Assembler programmiert werden. Für den Rest eignet sich prinzipiell jede höhere Programmiersprache. Bei Unix wurde erstmalig gezeigt, wie mit dem Einsatz von C der Assemblerteil auf ein Minimum reduziert werden kann. Nach diesem Vorbild wurden die Kernel praktisch aller größerer Betriebssysteme in C + Assembler implementiert, obwohl statt C auch C++, Pascal oder Fortran möglich wäre. Für die User-Space-Teile des Betriebssystems (Dienstprogramme) kann fast ohne Einschränkung jede Sprache (also bspw. auch Python, Java oder C#) verwendet werden, was auch gängige Praxis ist.
Yalu X. schrieb: > Bei Unix wurde erstmalig gezeigt, wie mit dem Einsatz von C der > Assemblerteil auf ein Minimum reduziert werden kann. Nein, dass war nicht Unix. Fortschrittlicher, in einem Algol-Ableger geschrieben, war MCP aus dem Jahr 1961 https://en.wikipedia.org/wiki/Burroughs_MCP Bei Multics, ebenso vor Unix, müsste mal wer nachschauen wie hoch der Assembleranteil war. Ansonsten war es in PL/1 implementiert Andere fürs Thema relevante Betriebssysteme wären u.a. A2/BlueBottle OS und das Oberon System. Zwar nicht in Pascal, aber in einem nahen Verwandten geschrieben: Oberon.
Warum eigentlich Pascal? Wer den C Syntax nicht (mehr) mag, nimmt Ada 2012 - das bessere Pascal!
C oder Pascal ist doch ein Streit um des Kaisers Bart. C hat sich in Breite und Tiefe durchgesetzt, Pascal ist genauso gut (zumindest hinzukriegen) aber warum sollten Leute wechseln. Man nimmt was neues, wenn man nicht weiter kommt. Für ganz neue, fortschrittliche Konzepte ist Pascal dann zu groß. Und nur wegen Vielfalt eine zweite Sprache ... ist Unsinn, im Gegenteil, es dient der Abgrenzung.
Weil Ada nicht auf so vielen Plattformen existiert? Pascal gibt es wie C für AVR, ARM, PIC etc pp Und nicht nur als experimentalversionen von einem Anbieter
:
Bearbeitet durch User
Arc N. schrieb: > Yalu X. schrieb: >> Bei Unix wurde erstmalig gezeigt, wie mit dem Einsatz von C der >> Assemblerteil auf ein Minimum reduziert werden kann. > > Nein, dass war nicht Unix. > Fortschrittlicher, in einem Algol-Ableger geschrieben, war MCP aus dem > Jahr 1961 https://en.wikipedia.org/wiki/Burroughs_MCP Danke, das kannte ich noch nicht. Wenn ich das richtig sehe, ist der Assembleranteil in MCP noch deutlich geringer als in Unix, nämlich schlichtweg 0. Deswegen sollte man nicht darüber streiten, ob C oder Pascal die bessere Sprache zur Implementierung von Betriebssystemen ist, sondern sich vielmehr fragen, warum aktuelle Betriebssysteme nicht in ESPOL oder NEWP geschrieben sind ;-)
Hallo, Yalu X. schrieb: > ...sondern sich vielmehr fragen, warum aktuelle Betriebssysteme > nicht in ESPOL oder NEWP geschrieben sind ;-) Nicht fragen, anfangen! rhf
Max S. schrieb: > Weil Ada nicht auf so vielen Plattformen existiert? Überall wo du gcc kriegst, kriegst du auch Ada (gnat-Compiler). Was Pascal und Betriebssysteme angeht: Das war nicht Wirths Intention. Pascal sollte eine 'sichere' klar gekapselte Sprache sein, die Direktzugriffe gar nicht erlaubt. Der Durchbruch für C war IMHO schon, dass die Freiheiten recht weitgreifend sind, um eben sowas wie Unix auf verschiedenen Architekturen laufenzulassen. Oberon ist sicher vom akademischen Standpunkt her die 'coole' Weiterentwicklung von Pascal/Modula2, usw., war aber an der ETH in den 90ern derart unbeliebt, dass die eigenentwickelte Rechnerarchitektur schnell wieder in der Versenkung verschwunden ist. Mit pragmatischem Engineering a la C hatte es N. Wirth nicht so, dafür waren seine Compilerbau-Vorlesungen excellent (wenn auch mal ein Schwamm flog, wenn ein Student in der VL quatschte). Der Vorteil einer spezifischen Sprache sind schlussendlich die Libraries und deren Wiederverwendbarkeit. Da hat C zumindest bei OS-Entwicklung und dem GNU-Oekosystem schlicht die besten Karten unterm Produktivitätsaspekt. Bei der Safety dafür weniger, aber dafür wird dann teils wieder lieber Ada genommen als Pascal.
Max S. schrieb: > Weil Ada nicht auf so vielen Plattformen existiert? Ähm? Doch! Was mich - unter anderem - von Ada für µC abgebracht hat, waren zwei Dinge: Die bescheidene Asm-Syntax. Das ist genauso "unelegant" wie unter C.
1 | Asm ("nop" & LF & HT &
|
2 | "nop" & LF & HT & |
3 | "nop"); |
In Pascal schreibe ich das einfach hin.
1 | asm |
2 | nop |
3 | nop |
4 | nop |
5 | end; |
Und das Headerfile-Konzept, hier mit .adb / .ads. Boah, das nervt. Brauchen doch andere Sprachen auch nicht...
"> Weil Ada nicht auf so vielen Plattformen existiert?" mag ja sein..nur welche fertigen Libs gibt es denn hier für Displays, Sensoren etc pp. Daher ist es keine Option. In Pascal gibt es genug fertige Units.
Max S. schrieb: > mag ja sein..nur welche fertigen Libs gibt es denn hier für Displays, > Sensoren etc pp. > Daher ist es keine Option. > In Pascal gibt es genug fertige Units. gcc -fdump-ada-spec generiert die passenden .ads files aus .h files der c-libs svd2ada verwendet man, wenn man eine mcu-name.svd Datei vom MCU Hersteller hat (arm-cortex). Ja, wer arduino-like nur Libs mit einer verknüpfen möchte, ist z.Z. mit Ada eher schlecht bedient, IMO.
Max S. schrieb: > mag ja sein..nur welche fertigen Libs gibt es denn hier für Displays, > Sensoren etc pp. Nur weil Du sie nicht kennst, heisst das nicht, dass sie nicht existieren. Ada wird eher in geschlossenen Systemen eingesetzt, da wird keiner seine Libs bei Github veröffentlichen. Und mal ehrlich, so eine Sensorlib von C auf Ada oder Pascal zu übertragen ist ja nun auch keine Raketentechnik.
Karl K. schrieb: > Und mal ehrlich, so eine Sensorlib von C auf Ada oder Pascal zu > übertragen ist ja nun auch keine Raketentechnik. Und wieso überhaupt, früher mal war es selbstverständlich Objectmodule verschiedener Sprachen zusammenzulinken. Es ist ja auch überhaupt kein Problem aus Pascal heraus die Windows-API zu verwenden, obwohl die sicher nicht in Pascal geschrieben ist. Natürlich muss man sich mit Aufrufkonventionen usw. befassen, z.B. ist die Reihenfolge der Parameter in Pascal umgekehrt wie in C, aber jemand für den das ein Hindernis ist sollte sich nicht Programmierer nennen. Georg
georg schrieb: > Und wieso überhaupt, früher mal war es selbstverständlich Objectmodule > verschiedener Sprachen zusammenzulinken. Naja, wenn ich Ada verwende, dann hat das bestimmte Gründe. Und einer der Gründe ist, nicht C zu verwenden. Es wäre ja reichlich sinnfrei, aus Sicherheitsgründen Ada zu schreiben und dann eine C-Lib einzubinden.
Karl K. schrieb: > Und mal ehrlich, so eine Sensorlib von C auf Ada oder Pascal zu > übertragen ist ja nun auch keine Raketentechnik. Zufällig wird Ada in der Raumfahrt verwendet, weil es so gut für sichere Embedded Systems ist.
georg schrieb: > Natürlich muss man sich mit Aufrufkonventionen usw. befassen, z.B. ist > die Reihenfolge der Parameter in Pascal umgekehrt wie in C, aber jemand > für den das ein Hindernis ist sollte sich nicht Programmierer nennen. Die Reihenfolge der Parameter ist ein kleines Problem gegenüber der deutlich unterschiedlichen Darstellung von Strings. Bei Pascal wird üblicherweise ein Längenfeld mitgeführt, wohingegen bei C die Nullterminierung üblich ist. Das ist fehlerträchtig ohne Ende, weil es nicht möglich ist, jeden gültigen Pascal-String als normalen String in C darzustellen. Das liegt aber eben daran, dass es in C eben keinen richtigen String-Typ gibt, sondern nur die Krücke mit char-Zeigern und char-Arrays. Gleiches gilt aber auch für das Zusammenfügen anderer Arrays.
Andreas S. schrieb: > Das ist fehlerträchtig ohne Ende, weil es > nicht möglich ist, jeden gültigen Pascal-String als normalen String in C > darzustellen Da kann ich nur noch mal darauf hinweisen, dass Pascal, egal ob Delphi oder Lazarus, selbstverständlich unter Windows läuft, also die Windows-API nutzt. Es scheint also Programmierer zu geben die mit den angeblichen Problemen fertig werden. In Delphi gibt es übrigens eine ganze Reihe Library-Funktionen für die "normalen Strings in C", z.B. StrCopy, StrCat usw. Georg
Dr. Sommer schrieb: > Zufällig wird Ada in der Raumfahrt verwendet, weil es so gut für sichere > Embedded Systems ist. Das war der Witz. georg schrieb: > Es scheint also Programmierer zu geben die mit den > angeblichen Problemen fertig werden. Die Konvertierung von nullterminierten Strings in längenkodierte ist Pillepalle im Zeitalter von AnsiString, Utf8, Utf16... DAS kann Dich wirklich in den Wahnsinn treiben.
:
Bearbeitet durch User
Karl K. schrieb: > DAS kann Dich > wirklich in den Wahnsinn treiben. Was ist Programmieren denn anderes als mühsam kontrollierter Wahnsinn? Georg
Karl K. schrieb: > Die Konvertierung von nullterminierten Strings in längenkodierte ist > Pillepalle Ich habe früher (genau: bis zur generellen Umstellung auf Unicode) in Pascal fast ausschliesslich mit nullterminierten Strings programmiert, eben weil die meisten Libraries, z.B. Windows und Datenbanken, auch diese verwendeten. Trotzdem ist glaube ich meine geistige Gesundheit noch intakt, aber das ist natürlich rein subjektiv. Du kannst es aber auch nicht besser beurteilen. Georg
Andreas S. schrieb: > Die Reihenfolge der Parameter ist ein kleines Problem gegenüber der > deutlich unterschiedlichen Darstellung von Strings. Bei Pascal wird > üblicherweise ein Längenfeld mitgeführt, wohingegen bei C die > Nullterminierung üblich ist. Das ist fehlerträchtig ohne Ende, weil es > nicht möglich ist, jeden gültigen Pascal-String als normalen String in C > darzustellen. Nimm einfach mikroPascal PRO von MikroElektronika, das verwendet ausschließlich nullterminierte Strings und ist auch sonst sehr stark an C angelehnt. Wahrscheinlich kann man diesen Pascalcode mit C-Code für den Compiler aus demselben Haus relativ problemlos mischen.
Dr. Sommer schrieb: > Die Konstrukte für den direkten > Speicher-Zugriff sind vom Standard nicht erlaubt Natürlich sind sie das.
Nop schrieb: > Natürlich sind sie das. Was passiert dann bei *((int*) 7) = 5 auf einer Implementierung, bei welcher Pointer ähnlich wie in Java umgesetzt sind und nur Referenz-nummern enthalten, und wo man überhaupt nicht auf den physikalischen Speicher zugreifen kann? Nirgendwo ist festgelegt, dass Pointer Speicher-Adressen enthalten.
Dr. Sommer schrieb: > Nirgendwo ist festgelegt, dass Pointer Speicher-Adressen enthalten. Ebenso ist nirgendwo festgeschrieben, daß die 7 zu einer Speicheradresse gecastet werden muß, sie kann auch als Referenznummer behandelt werden. Also kein Problem. Daß man mit so einer Implementierung kein memory mapped IO machen kann, ist die Entscheidung derer, die diese Implementierung gemacht haben. Sie haben effektiv eine VM gebaut, und daß man mit einer VM nicht an die Real-Hardware rankommt, ist ja der Zweck einer VM. Es gibt da ganz andere und reale Aspekte, bei denen man um Assembler nicht herumkommt, und zwar insbesondere Speicherbarrieren und Zugriffe auf den Stackpointer zwecks Kontextwechsel.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.