Proseminar TUM Informatik

Präsentation zum Thema: "Proseminar TUM Informatik"—  Präsentation transkript:

1 Proseminar TUM Informatik
PalmPilot und Handspring: Technik, Programmierung, Anwendung Aufbau und Struktur von Palm OS, Speichermanagement Stefan Kugele

2 Agenda Palm OS – Philosophie Struktur von Palm OS
Veränderungen zu Vorgängerversionen Speicherverwaltung Card Architektur RAM, chunks, heap, handles, pointer Memory Manager Beispiel Datenbank

3 Philosophie von Palm OS
Einfachheit Passt in die Westentasche Mobilität Erweiterbarkeit

4 Wo sind wir? Palm OS – Philosophie Struktur von Palm OS
Veränderungen zu Vorgängerversionen Speicherverwaltung Card Architektur RAM, chunks, heap, handles, pointer Memory Manager Beispiel Datenbank

5 Aufbau von Palm OS

6 Wo sind wir? Palm OS – Philosophie Struktur von Palm OS
Veränderungen zu Vorgängerversionen Speicherverwaltung Card Architektur RAM, chunks, heap, handles, pointer Memory Manager Beispiel Datenbank

7 Änderungen in Version 2.0 Neue Funktionen Änderungen TCP/IP support
IEEE Fließkommaberechnung Neue String-Manipulations-Funktionen Änderungen Verschiedene Dialoge, wie z.B. der System Keyboard Dialog

8 Änderungen in Version 3.0 Neue Funktionen Änderungen IR Support
Einmalige Geräte ID (nur bei Flash ROM) MIDI, asynchrone Sound-Wiedergabe Änderungen Dynamic heap wurde auf 96 KB vergrößert Storage RAM wird nun als ein großer heap implementiert

9 Änderungen in Version 3.5 Neue Funktionen Farbdisplay
Grafische Controls Sicherheits-Routinen Command bar enthält Buttons für häufig verwendete Menüeinträge Größe des dynamic heap richtet sich nach dem verfügbaren Speicher

10 Änderungen in Version 4.0 Neue Funktionen:
Verbesserte Sicherheit: Verschlüsselung von Daten, Passwortschutz Silent Alarms: Vibration oder LED-Blinken Unterstützung für Farben Schnurloser Internet- und -Zugang per Handy

11 Zukunft von Palm OS Wireless connections Sicherheit
Built-in Modems, „always-on“ -Verbindung Bluetooth Sicherheit Elektronischer Geldbeutel Grafik & Multimedia Höhere Auflösung, bessere Sound- und Video-Wiedergabe Stärkere Batterien, schnellere ARM Mikroprozessoren werden unterstützt

12 Zusammenfassung I Die Ziele sind in der Geschichte der Versionen deutlich zu erkennen: Unterstützung von TCP/IP, IrDA, Web Erhöhung der Sicherheit Verbessern des ‚Spaßfaktors‘ durch leichtere Bedienung, Farbdisplay Effizienteres Speichermanagement Mehr verfügbarer Speicher

13 Wo sind wir? Palm OS – Philosophie Struktur von Palm OS
Veränderungen zu Vorgängerversionen Speicherverwaltung Card Architektur RAM, chunks, heap, handles, pointer Memory Manager Beispiel

14 Hardware - card Ein Speichermodul besteht aus ROM, RAM oder beidem (card). Eine card ist eine logische Konstruktion, die vom OS verwendet wird. Ein Gerät kann mehrere cards enthalten (zur Zeit aber nur eine) Für jede card wird vom Palm OS 256 MB Adressraum reserviert

15 Speicher Architektur 32-bit Architektur mit 8, 16 und 32 bit langen Datentypen Somit stehen 4 GB als Adressraum zur Verfügung  großes Potential für die Zukunft Der erste Palm hat weniger als 0.025% des Adressraumes verwendet

16 RAM Der verfügbare RAM wird in zwei logische Bereiche zerteilt:
Dynamic RAM Globale Variablen, system-dynamische Allokationen (TCP/IP, IrDA) Größe variiert je nach OS, physikalischer Speicher, vorinstallierter Software Storage RAM Zum Speichern von persistenten Daten Datenbanken Dynamic RAM Storage RAM

17 Chunks I Alle Daten werden in memory manager chunks abgelegt.
Chunks sind kontinuierliche Speicherbereiche zwischen 1 Byte und etwas weniger als 64 KB. Die API hat keine generelle Beschränkung auf 64 KB.

18 Chunks II Chunks können beweglich und unbeweglich sein:
ROM-basierte heaps enthalten nur unbewegliche chunks. RAM-basierte heaps können beide Arten con chunks enthalten; sie sind also entweder dynamic heaps, oder storage heaps.

19 Chunk Struktur I 8 bytes header Chunk Daten Flags:sizeAdj byte
Höherwertige Nibble beinhaltet flags (1 bit wird für freien chunk gesetzt) Niederwertige Nibble beinhaltet size adjustment bits Size field (3 bytes) Lock:owner byte Höherwerige Nibble beinhalten den lock count Niederwerige Nibble beinhalten die owner ID hOffset field (3 bytes) Chunk Daten

20 Chunk Struktur II (Header)
Size (3 bytes) Flags [7-4] Size [3-0] Lock count [7-4] Owner ID [3-0] hOffset (3 bytes)

21 Heap - Überblick Ein heap ist ein kontinuierlicher Speicherbereich, der chunks enthält. Anwendungen können spezifizieren, ob sie neuen Speicher in dem dynamic oder im storage heap allozieren. Heaps werden über eine 16-bit, eindeutige heap ID referenziert.

22 Heap Struktur Heap header Master Pointer Table Chunks Heap Terminator
Heap ID, flags, size Master Pointer Table Pointers zu beweglichen chunks Chunks Beweglich, frei, gesperrt Heap Terminator Heap Header Master Pointer Table Heap Terminator Chunk .

23 Handles vs. Pointers Handles referenzieren master pointers
Pointer zeigen direkt auf die Daten Durch locken des handles bekommt man den pointer Heap Header Handle Master Pointer Table Chunk Chunk . Pointer Chunk Chunk Chunk Heap Terminator

24 Dynamic Heap I Der gesamte dynamic RAM wird benutzt, um einen einzigen dynamic heap zu erzeugen! Als Teil der Bootsequenz wird der dynamic heap reinitialisiert.

25 Dynamic Heap II Globale Daten für Palm OS TCP/IP stack
Font-Tabellen, Kernelstrukturen, event queue; meistens feste Größe TCP/IP stack Anwendungs-UI-Datenstrukturen Forms, windows, fields, tables, bitmaps, .. Dynamisch zugewiesener Speicher Anwendungs-Stack

26 OS 3.3-3.0 > 1 MB TCP/IR & IrDA
Dynamic Heap III RAM Verwen-dung OS 3.5  4 MB OS 3.5  2MB TCP/IP & IrDA OS > 1 MB TCP/IR & IrDA OS MB TCP/IP OS 2.0/ KB Dynami-scher Bereich 256 KB 128 KB 96 KB 64 KB 32 KB System Globals 40 KB  2,5 KB  2.5 KB TCP/IP stack 0 KB Verbleiben-der dynami-scher Platz 184 KB 56 KB  36 KB  12 KB

27 Storage Heaps Der restliche – nicht-dynamische Speicher – wird als ein oder mehr storage heap(s) konfiguriert (ab Version 3.X nur ein großer heap). Er beinhaltet nicht-flüchtige Daten wie Aufgaben, Adresslisten, Memos, ... Anwendungen greifen auf ihn zu, indem sie den data oder den ressource manager aufrufen.

28 Storage Heaps V1.0 & V2.0 64 KB     40 KB 50 KB

29 Storage Heaps V2.04 64 KB 40 KB 50 KB

30 Storage Heaps V3.0 256 KB 50 KB 120 KB

31 Memory Manager Verwaltet alle Heaps Stellt API zur Verfügung um:
Dynamic heap Storage heap ROM heap Stellt API zur Verfügung um: Allozieren von neuen chunks Löschen von chunks Locking, Resizing Defragmentieren von heaps

32 Verwenden des MM Allozieren: MemHandleNew, MemPtrNew
Verwenden: MemHandleLock / MemHandleUnlock Größe ändern: MemHandleResize / MemPtrResize Deallokation: MemHandleFree, MemPtrFree

33 Zusammenfassung II Der Memory Manager verwaltet den gesamten Speicher.
Dieser ist in dynamic und storage heap unterteilt und enthält chunks, welche beweglich und unbeweglich sein können. (1 byte - <64 KB) Zugriff nur per API !! Handles werden bei beweglichen und Pointer bei unbeweglichen chunks verwendet.

34 Beispiel aus der API-Doku
MemHandleNew Purpose: Allocate a new movable chunk in the dynamic heap and returns a handle to it. Prototype: MemHandle MemHandleNew (UInt32 size) Parameters: -> size The desired size of the chunk Result: Returns a handle to the new chunk, or 0 if unsuccessful. Comments: Use this call to allocate dynamic memory. Before you can write data to the memory chunk that MemHandleNew allocates, you must call MemHandleLock to lock the chunk and get a pointer to it.

35 Codebeispiel UInt8 AllocMemory() { UInt8* s; MemhandleSpielfeld = MemHandleNew(100); s=(UInt8*)MemHandleLock(memhandleSpielfeld); ... // z.B. Lese-, Schreibzugriffe MemHandleUnlock(memhandleSpielfeld); } UInt8 FreeMemory () { MemHandleFree(memhandleSpielfeld); return 0; © by Andreas Scholz

36 Datenbanken I Es stehen zwei unterschiedliche Manager zur Verfügung:
Data Manager Speichern von Benutzerdaten, Adressen, Memos, etc. Ressource Manager UI-Elemente von Anwendungen, Bilder, Fonts, oder ähnliches Beide sind sehr ähnlich, außer dass der ressource manager zusätzliche Informationen mitspeichert (+2 Byte)

37 Datenbanken II Jeder record (Datensatz) ist ein chunk.
Jeder record besitzt eine local ID, die auch im header der DB gesichert wird. Ein Aufrufer bekommt nach Konvertierung der local ID einen handle auf den record zurück.

38 Datenbanken III Warum kein gewöhnliches Dateisystem?
Da Daten direkt in der DB geändert werden, müssen sie nicht zuerst in den Speicher zum Ändern geladen werden.  Effizientere Speichernutzung! Records passen sehr schön in das Speicherkonzept von Palm OS Der DM verwendet den MM zur Allozierung von Speicher (Schichtenmodell)

39 Literatur www.palm.com www.palmos.com
Palm OS Programmer‘s Companion, Volume1, Juli 2001 Palm OS Programming Bible Vortrag wird unter abgelegt

40 Proseminar Vielen Dank für Euere Aufmerksamkeit