Zusammenfassung
In diesem Kapitel wird die Implementation des Modul-Konzeptes für MuPAD Release 1.2.2 vorgestellt und dabei insbesondere auf die technischen Verfahren zum dynamischen Einbinden des Maschinencodes eingegangen. Ein vollständiges Beispiel zur Modul-Programmierung in MuPAD 1.2.2 wird in Abschnitt 4.5 gegeben. Am Ende des Kapitels werden mögliche Änderungen und Erweiterungen der Modulverwaltung in folgenden MuPAD Releases sowie bei Verwendung von C++ vorgestellt.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
Aug. 1996: Sequent Symmetry, Sparc-Workstations, Silicon Graphics Convex/HP.
Diese wird ausführlich in der Arbeit [Mammut] beschrieben. 83 Anmerkung: Ein multi threaded kernel ist derzeit nicht konkret geplant. 84 Zum Beispiel die Handhabung ausführbarer Objekte, Funktionsattribute, remember table, die Darstellung unevaluierter Funktionsaufrufe, ... Vgl. hierzu [MuPAD]. 85 Vgl. hierzu [MuPAD], Abschnitt 2.3.16 Functions Environments, Seite 52.
Die Funktionsattribute werden zum Beispiel vom Differenzierer und Simplifier genutzt. Vgl. hierzu [MuPAD], Abschnitt 2.3.16.1 Attributes of Function Environments, Seite 53. 87 Vgl. hierzu [MuPAD], Abschnitt 2.3.17 Directly Executable Objects, Seite 55.
Benutzungsschnittstelle der Modulverwaltung, Vgl. hierzu Abschnitt A.2.2.
Das Standard-Modul stdmod wird in Anhang A.2.3 beschrieben. 93 Vgl. hierzu auch Seite 18 zum Stich wort „Verdrängung“. 94 Beispiele: module::help(“module”); module::help(“help”, “module”); 95 Vgl. hierzu Abschnitt 3.1.3. 96 Vgl. hierzu Seite 18: „Verdrängung“ und Seite 29: „call“.
Die Funktion call wird auf Seite 29 beschrieben. 98 Diese werden in Abschnitt 2.2.3 auf Seite 19f eingeführt.
Die Funktion init.generics wird auf Seite 34 beschrieben. 100 Pool der CAS-Objekte. Die Kerne eines Clusters haben getrennten Programmcode.
Ein Beispiel zur Funktion initmod wird im Anhang A.1.2 vorgestellt. 102 Vgl. hierzu Abschnitt 4.1 Seite 62ff.
Typischerweise weniger als 10 Module bzw. 10 Modulfunktionen. 104 Vgl. hierzu die Leistungsbewertung in Abschnitt 4.6 Seite 71ff.
Um die Übersicht zu erhöhen und die Wartung damit zu vereinfachen, enthält die Symboltabelle Lücken (NULL-Einträge). Sie kann damit nur als eine partielle injektive Abbildung verstanden werden. Vgl. hierzu auch symb_tab Seite 35.
Hierzu muß der MuPAD-Kern derzeit mit der Option -DMDMDEBUG übersetzt werden. 107 Eine mögliche Lösung dieses Problems wird in Abschnitt 3.3 Seite 60f diskutiert.
Stand Nov. 1995: Betroffene sind PC/Windows 3.11 und Apple Macintosh System 7.x. 109 Vgl. hierzu die Online-Manuals: man 1d und man 1d.so. 110 Vgl. hierzu das Online-Manual: man dlopen.
Unter SunOS 4.0.3 – 4.1.1 können shared libraries aufgrund eines Betriebssystemfehlers nicht korrekt ausladen. Vgl. SunSolve (Bugs, Patches) zum Stichwort „ld“. Hier wird der Kern mit der Option NOMDM_UNLOAD übersetzt. Vgl. hierzu Seite 50.
Unter der Betriebssystem-Version IRIX-4.X wird das shared library-Konzept leider noch nicht angeboten. Hier können durch MuPAD nur Pseudomodule unterstützt werden.
Vgl. hierzu das Online-Manual: man load.
Unter älteren Betriebssystemversionen mit dem a.out Binary-Format wird das shared library-Konzept in dieser Form leider noch nicht unterstützt. Hier kann jedoch das dld-Paket eingesetzt werden. Es ist frei verfügbar unter tsx-ll.mit.edu:/pub/linux/sources/libs/ Dort sind weitere Informationen und eine genaue Beschreibung der Funktionalität zu finden.
Stand: Dez. 1995, Apple 68k-Macintosh. 116 Vgl. hierzu Abschnitt 4.2 Seite 64ff. 117 Stand: MuPAD Release 1.2.9, Mai 1996
Vgl. hierzu Seite 52.
Vgl. hierzu Abschnitt 2.3.5, insbesondere Abbildung 5 auf Seite 38.
Diese werden in Abschnitt 2.2.2, Seite 18 vorgestellt.
Vgl. hierzu die Funktion info Seite 45 und 70.
Eine mögliche Realisierung der Interface-Ebene in C++ wird in Abschnitt 3.3 diskutiert.
Mit der Erweiterung der Kern-/Modul-Programmierschnittstelle für das MuPAD Release 1.3 werden weitere Makros zur Definition von Modulfunktionen zur Verfügung gestellt. 124Vgl. hierzu Abschnitt 4.3.
Vgl. hierzu Eine Speicherverwaltung in C++, MuPAD, Holger Naundorf, März ’94.
Der MuPAD-Kern und seine Speicherverwaltung sind in ANSI-C implementiert. Zum Einbinden von C++ Modulen muß der Modulgenerator eine (kleine) Erweiterung erfahren, da ANSI-C und C++ Unterschiede im Format ihres Linkage (insbesondere der Symboltabelle) aufweisen. Vgl. hierzu auch [C++] Seite 132 und 577ff.
Vgl. hierzu auch [C++] Seite 124, 167 und 602. 128 Vgl. hierzu Abschnitt 4.4.
Die Symboltabelle symb_tab wird auf Seite 35 beschrieben.
Dies kann zudem anderen Mechanismen dienen, z.B.: Spezielle Deklaration von globalen Variablen im Falle eines multi threacted Kerns, Markieren von Systemfunktionen für den CAS-Interpreter, Markieren globaler shared memory Variablen für den Garbage Collector, ...
Stand: Herbst 1995, MuPAD Release 1.2.2.
Vgl. hierzu auch Seite 59.
Vgl. hierzu auch das UNIX manual nm(1).
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 1996 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
Sorgatz, A. (1996). Eine Modulverwaltung für MuPAD. In: Dynamische Module. MuPAD Reports. Vieweg+Teubner Verlag, Wiesbaden. https://doi.org/10.1007/978-3-322-93082-8_3
Download citation
DOI: https://doi.org/10.1007/978-3-322-93082-8_3
Publisher Name: Vieweg+Teubner Verlag, Wiesbaden
Print ISBN: 978-3-519-02195-7
Online ISBN: 978-3-322-93082-8
eBook Packages: Springer Book Archive