Forum: PC-Programmierung Pascal für Betriebssysteme


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Max S. (maximus-minimus)


Bewertung
-5 lesenswert
nicht lesenswert
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
von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max S. schrieb:
> ein neuer Ansatz.

Ansatz wozu ? Streiterei, Fanboywerbung ?

Nimm einfach die Realität an, dann erspart sich jede Bierzeltdiskussion.

von georg (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Hannes J. (Firma: professional Professional) (pnuebergang)


Bewertung
-4 lesenswert
nicht lesenswert
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.

von Dr. Sommer (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Max S. (maximus-minimus)


Bewertung
1 lesenswert
nicht lesenswert
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

von Max S. (maximus-minimus)


Bewertung
1 lesenswert
nicht lesenswert
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
von Yalu X. (yalu) (Moderator)


Bewertung
5 lesenswert
nicht lesenswert
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.

von Arc N. (arc)


Bewertung
0 lesenswert
nicht lesenswert
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.

von IOCCC Gewinner (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Warum eigentlich Pascal?

Wer den C Syntax nicht (mehr) mag, nimmt Ada 2012 - das bessere Pascal!

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Max S. (maximus-minimus)


Bewertung
0 lesenswert
nicht lesenswert
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
von safari (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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 ;-)

von Roland F. (rhf)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Yalu X. schrieb:

> ...sondern sich vielmehr fragen, warum aktuelle Betriebssysteme
> nicht in ESPOL oder NEWP geschrieben sind ;-)

Nicht fragen, anfangen!

rhf

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Karl K. (karl2go)


Bewertung
0 lesenswert
nicht lesenswert
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.
Asm ("nop" & LF & HT &
      "nop" & LF & HT &
      "nop");

In Pascal schreibe ich das einfach hin.
asm
  nop
  nop
  nop
end;

Und das Headerfile-Konzept, hier mit .adb / .ads. Boah, das nervt. 
Brauchen doch andere Sprachen auch nicht...

von Max S. (maximus-minimus)


Bewertung
0 lesenswert
nicht lesenswert
"> 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.

von IOCCC Gewinner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Karl K. (karl2go)


Bewertung
0 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Karl K. (karl2go)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Dr. Sommer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Karl K. (karl2go)


Bewertung
0 lesenswert
nicht lesenswert
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
von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> DAS kann Dich
> wirklich in den Wahnsinn treiben.

Was ist Programmieren denn anderes als mühsam kontrollierter Wahnsinn?

Georg

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Die Konstrukte für den direkten
> Speicher-Zugriff sind vom Standard nicht erlaubt

Natürlich sind sie das.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.