Proseminar TUM Informatik PalmPilot und Handspring: Technik, Programmierung, Anwendung Aufbau und Struktur von Palm OS, Speichermanagement 08.11.2001 Stefan Kugele kugele@in.tum.de

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

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

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

Aufbau von Palm OS

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

Ä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

Ä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

Ä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

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

Zukunft von Palm OS Wireless connections Sicherheit Built-in Modems, „always-on“ E-Mail-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

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

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

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

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

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

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.

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.

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

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

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.

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 .

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

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.

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

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 3.3-3.0 > 1 MB TCP/IR & IrDA OS 2.0 1 MB TCP/IP OS 2.0/1.0 512 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

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.

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

Storage Heaps V2.04 64 KB 40 KB 50 KB

Storage Heaps V3.0 256 KB 50 KB 120 KB

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

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

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.

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.

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

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)

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.

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)

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

Proseminar Vielen Dank für Euere Aufmerksamkeit