------------------------------- Dokumentation zum Modula-System Stand 17.5.88 ------------------------------- 1.0 Zusammenstellen der Disketten : ----------------------------------- Da die Disk-Kapazit„t begrenzt ist, ist es sinnvoll mit 2 Disketten zu arbeiten. 1) STARTDISK : ben”tigt - AUTO (Ordner) - GEMLIB (Ordner) - STDLIB (Ordner) - SYSTEM (Ordner) - COPY.LST ( Liste der Files die in die Ramdisk berspielt werden ) - DEBUG.RSC - EDITOR.PRG ( eigener Editor ) - ERROR.IND ( Fehlermeldungen fr Compiler ) - M2PATH.TXT ( Suchpfade der MODULA-SHELL ) - NEWSHELL.RSC sinnvoll ist es aužerdem die SDM-Files (= SYMBOL-DEFN-Files die die zum compilieren ben”tigt werden in die RAM-Disk in den Ordner SBM zu legen.) 2) ARBEITSDISK : ben”tigt - DEFN ( Ordner nur mit .DEFN - Files ) - WORK ( leerer Ordner zum compilieren & arbeiten ) - STANDALONE ( wird nur ben”tigt, wenn .PRG - Files codiert werden siehe auch unter Punkt 3.2 ) 2. Modula-Shell : ----------------- 2.1 Hochfahren des Systems - ATARI einschalten - START Diskette einlegen ... Der ATARI bootet und installiert die RAM - Disk dies best„tigen Sie mit RETURN ... Einige Files (auch EDITOR.PRG !) werden in die RAM - Disk geladen Nun k”nnen Sie die fr ihr Programm n”tigen SBM-Files in die RAM-Disk kopieren (Das compilieren geht wesentlich schneller) Jetzt wird der M2LOADER durch Sie auf der RAM-DISK gestartet. Im LOADER starten Sie M2SHELL.OBM durch bet„tigen der RETURN-Taste. ...Die Modula-Shell wird nun geladen. Jetzt mssen Sie nur noch das DATUM eingeben, falls dies noch nicht geschehen ist und schon kann's losgehen. - ARBEITSDISK ins Laufwerk und ran an die Arbeit. Nun k”nnen Sie ein Programm bersetzen, indem Sie unter Datei bersetzen ( Erzeugung eines CodeFiles .OBM) oder PRG erzeugen (Erstellen eines direkt lauff„higen Programms, siehe auch 3.2) anw„hlen. Zus„tzliche Hinweise : Um in der Shell die Editierfunktion bentzen zu k”nnen, mssen Sie den Namen eines Textverarbeitungsprogrammes oder Editors (z.B. Tempus, ... ) auf EDITOR.PRG „ndern und dieses File auf die Compiler-Diskette bzw. die START-DISK kopieren. 3.0 Informationen ber M2SHELL / MODULA-Comliler : -------------------------------------------------- 3.1 allgemeines: Die Arbeitsumgebung ist in Schalen aufgebaut. Unterste Schale ist der M2Loader. (In Wirklichkeit liegt da noch so einiges an Be- triebssystem, GEM etc. drunter, das ist immer da und interessiert uns nicht weiter.) Auf M2Loader liegt dann M2Shell. Dies ist ein nicht gelinktes Objetmodul d.h. es kann nicht ohne denM2Loader laufen. M2Shell ruft dann ihrerseits Editor und Compiler auf. Wird ein compiliertes Programm gestartet so l„uft es, wenn es noch nicht gelinkt ist, wie alle .OBM Programme unter Kontrolle von M2LOADER, der bei Laufzeitfehlern den Debugger starten kann. M2SHELL, der Compiler und der Debugger bleiben wenn sie einmal geladen sind resident. Um dem Benutzer das Leben zu erleichtern gibt es die Datei M2PATH.TXT. Diese Datei kann wie jede Textdatei mit dem Editor bearbeitet werden. In ihr stehen Suchpfade die der Compiler, der Debugger und M2LOADER auf der Suche nach Dateien benutzen. Aužer- dem kann der Defaultaufruf des M2LOADER eingetragen werden. D.h. der Name der in der letzten Zeile nach @M steht kann durch an- klicken von "O.K" gestartet werden. In der vorletzten Zeile dieser Datei steht der Suchpfad, der als Default fr fr Funktionen wie Modul ausw„hlen verwendet wird. 3.2 stand-alone Programme: Da man, wenn man "ernsthaft" programmieren will Programme ohne den Schutz von M2LOADER laufen lassen will muss man die compi- lierten Objektmodule binden (linken). Dazu muž sich der Ordner STANDALO.NE auf dem Laufwerk befinden, von dem M2LOADER geladen wurde, d.h. Benutzer einer RAM-Disk mssen diesen Ordner samt Inhalt per Maus, oder per COPY.LST automatisch in die Ramdisk kopieren. Der Linker wird durch "PRG erzeugen" gestartet. Er sucht sich dann alles zusammen, was er braucht (LINKER.OBM,PATH.OBM,HEAP.OBM,...) linkt dann ein lauff„higes .PRG-File aus allen n”tigen .OBM-Files (Diese mssen dann auch vorhanden sein oder per Hand von anderen Disks angew„hlt werden !!!) zusqammen und berprft auf Versionskonflikte. Findet er etwas nicht, so gibt er dem Benutzer die Chance per "Hand" die gesuchten Module zu finden. 3.3 Der Debugger Wie der Compiler stammt auch der Debugger aus dem Geburtsort von Modula-2, aus der ETH Zrich. Der Debugger ist ein symbolischer Post-Mortem-Debugger. Das heist er wird nach einem Laufzeitfehler vom M2LOADER gestartet und zeigt nicht irgendwelche Speicherin- halte sondern verwendet die Programmsource. Die Fehlerzeile ist fett gedruckt. Alle beim Fehlerauftritt sichtbaren Variablen k”n- nen angezeigt weden. Es gibt fnf Fenster: - Quelltext: Da steht (hoffentlich) der Quelltext drin in dem der Fehler auf- trat. Wenn nichts drin steht fehlt der Quelltext. Wenn der Quell- text in einem der Suchpfade liegt fhrt das Anklicken des Modul- namens im Modulfenster (meistens) zum Erfolg. - Prozeduraufrufkette und Datenfenster 1: Dies beiden Fenster geh”ren zusammen. Das linke Fenster (Proze- duraufrufkette) zeigt in welcher Reihenfolge die Prozeduren auf- gerufen wurden. Da stehen auch die Prozeduren des M2LOADER drin. - Modulliste und Datenfenster 2: Hier gilt gleiches wie oben, nur daž hier Module angezeigt werden und die dort sichtbaren Variablen. Durch anklicken von Prozedur/Modulnamen kann man dies Proze dur/Modul betrachten. Zu den Datenfenstern ist die Darstellung der Arrays und der Records zu erw„hnen. Beide sind durch "*" gekenzeichnet. Klickt man diesen an "betritt" man das Array/Record. In der ersten Zeile des Fensters erscheint nach einem "." der Name der angeklickten Variablen. Bei tiefer struckturierten Datentypen k”nnen dort durchaus mehrer Bezeichner durch "." getrennt hintereinander stehen. Durch Anklicken der Bezeichner kann man wieder "herauf" steigen.