Stuttgart, Univ., Fachstudie, 2002.

Programming PLC systems is limited by the provided libraries. In contrary, hardware-near programming needs bigger efforts in e. g. initializing the hardware. This work others a foundation to combine advantages of both development sides. Therefore, Portable.NET from the DotGNU project has been used, which is an implementation of CLI, better known as “.NET”. The target system is the PLCcore-5484 microcontroller board, developed by SYS TEC electronic GmbH. Built upon the porting, two variants to use interrupt routines withing the Portabe.NET runtime environment have been analyzed. Finally, the reaction times to occuring interrupt events have been examined and compared. / Die Programmierung für SPS-Systeme ist durch die gegebenen Bibliotheken beschränkt, während hardwarenahe Programmierung einen größeren Aufwand durch z.B. Initialisierungen hat. Diese Arbeit bietet eine Grundlage, um die Vorteile beider Entwicklungsseiten zu kombinieren. Dafür wurde Portable.NET des DotGNU-Projekts, eine Implementierung des CLI, bekannter unter dem Namen “.NET”, benutzt. Das Zielsystem ist das PLCcore-5484 Mikrocontrollerboard der SYS TEC electronic GmbH. Aufbauend auf der Portierung wurden zwei Varianten zur Einbindung von Interrupt-Routinen in die Portable.NET Laufzeitumgebung untersucht. Abschließend wurden die Reaktionszeiten zu eintretenden Interrupts analysiert und verglichen.

Programming PLC systems is limited by the provided libraries. In contrary, hardware-near programming needs bigger efforts in e. g. initializing the hardware. This work others a foundation to combine advantages of both development sides. Therefore, Portable.NET from the DotGNU project has been used, which is an implementation of CLI, better known as “.NET”. The target system is the PLCcore-5484 microcontroller board, developed by SYS TEC electronic GmbH. Built upon the porting, two variants to use interrupt routines withing the Portabe.NET runtime environment have been analyzed. Finally, the reaction times to occuring interrupt events have been examined and compared.:Contents List of Tables iv List of Figures v Listings vi 1 Introduction 1 1.1 Objective 1 1.2 Structure 2 2 State of the Art 3 2.1 .NET Framework 3 2.1.1 Common Language Runtime 4 2.1.2 Common Type System 6 2.1.3 Common Language Specification 6 2.1.4 Common Intermediate Language 7 2.1.5 Metadata 8 2.1.6 .NET Class Library 8 2.2 DotGNU 9 2.2.1 Hans-Boehm Garbage Collector 10 2.2.2 Foreign Function Interface 11 2.2.3 Interpreter 11 2.2.4 Unrolled Assembler Code 12 2.2.5 JIT Support 13 2.2.6 Debugging 14 2.2.7 X11 Support 16 2.2.8 Embedded Engine 16 2.3 Mono 17 2.4 Rotor 27 2.5 Coldfire vs. m68k 17 2.5.1 Exclusive Instructions 18 2.5.2 Floating Point Size 18 2.5.3 Other Differences 19 2.5.4 ABI Changes 19 3 Implementation 20 3.1 Incompatible m68k Code 20 3.2 Incompatible Alignments 21 3.3 Broken Toolchain 24 3.4 Unrolling Assembler Code 24 3.4.1 Setup of the Unroller 25 3.4.2 Unroller Implementation 26 3.4.3 m68k Specifics 27 3.4.4 Macro Counting 28 3.4.5 Extended Testsuite 29 3.4.6 Floating Point Remainder 34 3.4.7 Big Endianess 34 3.4.8 NOP is not just no Operation 36 3.4.9 Caches 36 3.5 C# Debugging 37 3.6 Interrupt Access in C# 38 3.6.1 Kernel Module 39 3.6.2 C# Application 40 3.7 Results 42 4 Performance 43 4.1 Portable.NET Benchmark 43 4.2 Benchmark Results 44 4.3 Interrupt Response Time 46 5 Final Remarks and Further Work 53 5.1 Conclusion 53 5.2 Improvements 53 5.2.1 Increasing Engine Performance 53 5.2.2 Tweaking IRQ Handling 54 5.2.3 Porting JIT to MCF5484 55 5.2.4 Miscellaneous 55 6 Acronyms 56 Bibliography 58 A Contents of the enclosed CD 61 / Die Programmierung für SPS-Systeme ist durch die gegebenen Bibliotheken beschränkt, während hardwarenahe Programmierung einen größeren Aufwand durch z.B. Initialisierungen hat. Diese Arbeit bietet eine Grundlage, um die Vorteile beider Entwicklungsseiten zu kombinieren. Dafür wurde Portable.NET des DotGNU-Projekts, eine Implementierung des CLI, bekannter unter dem Namen “.NET”, benutzt. Das Zielsystem ist das PLCcore-5484 Mikrocontrollerboard der SYS TEC electronic GmbH. Aufbauend auf der Portierung wurden zwei Varianten zur Einbindung von Interrupt-Routinen in die Portable.NET Laufzeitumgebung untersucht. Abschließend wurden die Reaktionszeiten zu eintretenden Interrupts analysiert und verglichen.:Contents List of Tables iv List of Figures v Listings vi 1 Introduction 1 1.1 Objective 1 1.2 Structure 2 2 State of the Art 3 2.1 .NET Framework 3 2.1.1 Common Language Runtime 4 2.1.2 Common Type System 6 2.1.3 Common Language Specification 6 2.1.4 Common Intermediate Language 7 2.1.5 Metadata 8 2.1.6 .NET Class Library 8 2.2 DotGNU 9 2.2.1 Hans-Boehm Garbage Collector 10 2.2.2 Foreign Function Interface 11 2.2.3 Interpreter 11 2.2.4 Unrolled Assembler Code 12 2.2.5 JIT Support 13 2.2.6 Debugging 14 2.2.7 X11 Support 16 2.2.8 Embedded Engine 16 2.3 Mono 17 2.4 Rotor 27 2.5 Coldfire vs. m68k 17 2.5.1 Exclusive Instructions 18 2.5.2 Floating Point Size 18 2.5.3 Other Differences 19 2.5.4 ABI Changes 19 3 Implementation 20 3.1 Incompatible m68k Code 20 3.2 Incompatible Alignments 21 3.3 Broken Toolchain 24 3.4 Unrolling Assembler Code 24 3.4.1 Setup of the Unroller 25 3.4.2 Unroller Implementation 26 3.4.3 m68k Specifics 27 3.4.4 Macro Counting 28 3.4.5 Extended Testsuite 29 3.4.6 Floating Point Remainder 34 3.4.7 Big Endianess 34 3.4.8 NOP is not just no Operation 36 3.4.9 Caches 36 3.5 C# Debugging 37 3.6 Interrupt Access in C# 38 3.6.1 Kernel Module 39 3.6.2 C# Application 40 3.7 Results 42 4 Performance 43 4.1 Portable.NET Benchmark 43 4.2 Benchmark Results 44 4.3 Interrupt Response Time 46 5 Final Remarks and Further Work 53 5.1 Conclusion 53 5.2 Improvements 53 5.2.1 Increasing Engine Performance 53 5.2.2 Tweaking IRQ Handling 54 5.2.3 Porting JIT to MCF5484 55 5.2.4 Miscellaneous 55 6 Acronyms 56 Bibliography 58 A Contents of the enclosed CD 61

„Remote Scripting“-Anwendungen erleben seit einigen Jahren einen regelrechten Anfrageboom. Während aus usability-Sicht bisher eine strikte Unterscheidung zwischen Desktop-Anwendungen und Webapplikationen herrschte, finden sich seit einiger Zeit zunehmend Angebote im World Wide Web, die diese strikte Trennung verwischen lassen. Interaktive Nutzerdialoge, nebenläufige Prozessabarbeitung und visuelle Unterstützungsmittel wie Drag & Drop- Effekte halten auf Webseiten Einzug, die dem Nutzer bisher nur aus eigenständigen Softwareprodukten in einer spezifischen Betriebssystemumgebung bekannt waren. Viele dieser neuen Anwendungs- und Interaktionsmöglichkeiten im weltweiten Datennetz werden inzwischen unter dem Oberbegriff Web 2.0 zusammengefasst. Für den Nutzer bringt dieser neue Entwicklungstrend viele Vorteile: Ansprechende, intuitive Nutzerführungen ohne die Notwendigkeit, eine ganze Internetseite bei jedem Interaktionsschritt neu zu laden und ohne bemerkbaren zeitlichen Overhead. Was für den Nutzer Erleichterung bringen soll, bedeutet häufig für einen Programmierer zunächst Mehraufwand. Eine Technik zur Realisierung solcher so genannten Rich Internet Applications, die sich in den letzten beiden Jahren immer mehr in den Vordergrund gedrängt hat, wird unter der Bezeichnung AJAX zusammengefasst. Einen einheitlichen Standard gibt es dabei nicht, sodass fast täglich neue AJAX-basierte frameworks veröffentlicht werden, die dem Programmierer (wenigstens einen Teil der) Komplexität der Programmflusssteuerung abnehmen sollen. Aufgabe der Studienarbeit soll es daher sein, das inzwischen unüberschaubar gewordene Angebot an AJAX frameworks zu systematisieren und einen Überblick über Vor- und Nachteile ausgewählter Programmbibliotheken zu geben. Dafür ist ein Kriterienkatalog zu erarbeiten, der eine Bewertung der verschiedenen frameworks nach unterschiedlichen Gesichtspunkten ermöglicht. Besonderer Schwerpunkt ist dabei auf Kriterien aus Programmierersicht (Sprachunabhängigkeit, Overhead, Implementierungsmöglichkeiten,…) und Anwendersicht (Plattformanforderungen, Einarbeitungszeit, Ergebnisqualität, …) zu legen. Auf den Kriterienkatalog ist anschließend eine Auswahl an bereits existierenden, frei verfügbaren AJAX frameworks anzuwenden, die als zukünftig relevant eingeschätzt werden. Die Ergebnisse sind abschließend in einer Gesamtübersicht zu präsentieren, die eine objektive Empfehlung für Nutzer darstellen soll, die vor der Wahl stehen, welche AJAX Programmbibliothek sie zukünftig einsetzen sollten.

Chemnitz, Techn. Univ., Studienarb., 2007.

„Remote Scripting“-Anwendungen erleben seit einigen Jahren einen regelrechten Anfrageboom. Während aus usability-Sicht bisher eine strikte Unterscheidung zwischen Desktop-Anwendungen und Webapplikationen herrschte, finden sich seit einiger Zeit zunehmend Angebote im World Wide Web, die diese strikte Trennung verwischen lassen. Interaktive Nutzerdialoge, nebenläufige Prozessabarbeitung und visuelle Unterstützungsmittel wie Drag & Drop- Effekte halten auf Webseiten Einzug, die dem Nutzer bisher nur aus eigenständigen Softwareprodukten in einer spezifischen Betriebssystemumgebung bekannt waren. Viele dieser neuen Anwendungs- und Interaktionsmöglichkeiten im weltweiten Datennetz werden inzwischen unter dem Oberbegriff Web 2.0 zusammengefasst. Für den Nutzer bringt dieser neue Entwicklungstrend viele Vorteile: Ansprechende, intuitive Nutzerführungen ohne die Notwendigkeit, eine ganze Internetseite bei jedem Interaktionsschritt neu zu laden und ohne bemerkbaren zeitlichen Overhead. Was für den Nutzer Erleichterung bringen soll, bedeutet häufig für einen Programmierer zunächst Mehraufwand. Eine Technik zur Realisierung solcher so genannten Rich Internet Applications, die sich in den letzten beiden Jahren immer mehr in den Vordergrund gedrängt hat, wird unter der Bezeichnung AJAX zusammengefasst. Einen einheitlichen Standard gibt es dabei nicht, sodass fast täglich neue AJAX-basierte frameworks veröffentlicht werden, die dem Programmierer (wenigstens einen Teil der) Komplexität der Programmflusssteuerung abnehmen sollen. Aufgabe der Studienarbeit soll es daher sein, das inzwischen unüberschaubar gewordene Angebot an AJAX frameworks zu systematisieren und einen Überblick über Vor- und Nachteile ausgewählter Programmbibliotheken zu geben. Dafür ist ein Kriterienkatalog zu erarbeiten, der eine Bewertung der verschiedenen frameworks nach unterschiedlichen Gesichtspunkten ermöglicht. Besonderer Schwerpunkt ist dabei auf Kriterien aus Programmierersicht (Sprachunabhängigkeit, Overhead, Implementierungsmöglichkeiten,…) und Anwendersicht (Plattformanforderungen, Einarbeitungszeit, Ergebnisqualität, …) zu legen. Auf den Kriterienkatalog ist anschließend eine Auswahl an bereits existierenden, frei verfügbaren AJAX frameworks anzuwenden, die als zukünftig relevant eingeschätzt werden. Die Ergebnisse sind abschließend in einer Gesamtübersicht zu präsentieren, die eine objektive Empfehlung für Nutzer darstellen soll, die vor der Wahl stehen, welche AJAX Programmbibliothek sie zukünftig einsetzen sollten.