Nachrichten

41

Offtopic / Re: binäre Division

« am: 30. November 2012, 15:06 »

http://www.informatik.uni-ulm.de/ni/Lehre/SS01/TI/folien/arithC2.pdf

da hst du sogar ein blockschaltbild

Danke für den Link.

Mein Problem ist halt, dass die Subtraktionen voneinander abhängen und ich sie nicht parallelisieren kann. Um alle Fälle abzudecken bräuchte man jede Menge Register und Addierer.

Dieses SRT interessiert mich, da die Operanden zuvor analysiert werden.

Alles in allem scheint die Division eine teure Angelegenheit zu werden.

42

Offtopic / binäre Division

« am: 30. November 2012, 12:47 »

Zur Evaluierung und Ausarbeitung verschieder Ansätze für parallele Architekturen habe ich letztens ein paar Schaltungen für Addierer und Multiplizierer konstruiert. Kurz: Addierer mit n Chipfläche und in log(n) Zeit, sowie Multiplizierer mit 2n Fläche und 2log(n)+x Zeit für Bitbreite n=128 und kleinem x. Packed integer werden unterstützt.

Einen Multiplizierer mit log(n) Zeit und n^2 Platz habe ich verworfen.

Pro Instruktion sind mehrere Schaltungen parallel vorgesehen. Die Kosten berechne ich näherungsweise mit Taktzyklen * Transistoren(d.h. Chipfläche), würde aber kürzere Taktzyklen bevorzugen (Serialisierung).

Nun bin ich auf der Suche nach Ideen für die Division, welche über die schriftliche Division hinausgehen. In der englischen Wikipedia gibt es dazu den Artikel: Division algorithm, der sich mir jedoch nicht ganz erschließt.

Kennt jemand die Schaltungen in aktuellen Prozessoren von Intel/ARM/GraKas etc?

Ich habe bisher noch keinen guten EDA-Designer gefunden, die freien sind etwas unhandlich, oder es fehlt etwas, bspw Logikbausteine, Timing-Simulation oder Export in ein standardisiertes Format.

SORRY NOCH NICHT FERTIG... bis gleich : )

43

Softwareentwicklung / Re: "uint8_t" kennt mein GCC nicht

« am: 04. November 2012, 21:20 »

Für aufstrebende C-Programmierer gibt es an anderer Stelle spezielle Foren zum Lernen der Sprache. Alternativ brauch man nicht notwendigerweise Programmierkenntnisse, um einen Open-Source-Kernel - ein Linux etwa - selbst zu kompilieren.

44

OS-Design / Re: Was kann das OS

« am: 30. October 2012, 23:27 »

Was habt ihr alle gegen Ubuntu? Ich bin seit einem Jahr wunschlos mit Ubuntu glücklich!

Wir haben seit weit über einem Jahr immer wieder komische Probleme gedebuggt, die nur mit Ubuntu aufgetreten sind. Sonst eigentlich nichts.

Das hat evtl. was mit der stärkeren Verbreitung/Verwendung von Ubuntu zu tun.

45

Lowlevel-Coding / Re: Nicht durch das Multiboot-MMap beschriebene Adressräume

« am: 15. October 2012, 06:10 »

Dazu hätte ich dann auch eine Frage: die reservierten/gemappten Bereiche liegen nach dem Bootvorgang doch ausschließlich unterhalb von 1MB sowie irgendwo knapp unter 4GB, oder liege ich da falsch?

46

Lowlevel-Coding / Re: Probleme durch Multitasking

« am: 09. October 2012, 12:30 »

Die Lösung für dein Problem heisst: Debuggen.

Das Einfachste ist, du schickst zeilenweise Statuslogs and die serielle Konsole.

Kommt der Interrupt überhaupt aus dem Handler?
Sind die Tastatur-Buffer threadsafe? ie sind sie synchronisiert?

Gruß

47

Das Wiki / Sourcecode unvollständig in Android-Browser

« am: 09. October 2012, 12:17 »

Bei den formatierten Code Listings fehlt bei mir der Scrollbalken. Nachdem ich nach einem Update nicht mehr auf den Seiten-Quelltext zugreifen kann, sehe ich keine Möglichkeit das Listing in seiner Vollständigkeit einzusehen. Auf meinem Ubuntu funktioniert alles normal.

48

OS-Design / Re: Verwaltung von Threads

« am: 29. September 2012, 20:56 »

Mit "kombinieren" war gemeint, dass die struct der Baumstruktur zusätzlich zu den Eigenschaften parent und childList die Eigenschaften taskNext und -Prev, sowie activeNext und -Prev zu bekommt. Optional können durch weitere verkettete Listen Prioritäten und Synchronisierung implementiert werden. Mir ist nicht klar, inwiefern dein Scheduler Kind-Prozesse unterstützt, aber auch hier sollte der Aufwand im Scheduler mit steigender Anzahl der Tasks ebenfalls konstant bleiben.

Gruß

49

OS-Design / Re: Verwaltung von Threads

« am: 24. September 2012, 15:57 »

@TeThing: kombiniere die Baumstruktur mit verketteten Listen für alle Taks und für die aktive Untermenge. Der Scheduler läuft dann konstant und nutzt die vollständige Liste für suspend/resume.

Gruß

50

Softwareentwicklung / Re: Wie kann man die Zuverlässigkeit von Software und Computern steigern?

« am: 22. August 2012, 12:50 »

Die Ausführung würde in der Tat von einem Hypervisor verwaltet werden, welcher Speicherzugriffe pro Funktionsblock in einem privilegierten Modus und den eigentlichen Code im Usermode ausführt. Das betrifft dann allerdings nur den kritischen Teil des Kernels, etwa den Scheduler. Diese "Trusted Computing Base" kann bei Microkerneln vergleichsweise klein gehalten werden.

Ergänzung zur Liste aus dem 1. Posting:

• Typinformationen für Zeiger und Datenstrukturen sollten Bestandteil der Allokations-Details sein.
• fest definierte Einsprungspunkte der Funktionsblöcke. An bestimmten Stellen, zumindest vor Daten sollte Code stehen, der das System anhält.
• die Isolation von Einheiten und Zuständen soll bewirken, dass selbst bösartiger Code und besondere Kombinationen von Eingabewerten ohne Auswirkungen auf das Verhalten oder die Integrität des Systems bleiben.
• dem entsprechend kann Usermode-Code keinen Kernel-Code verdrängen

Gruß

51

OS-Design / Re: Kernel malloc/free, kompakt und leichtgewichtig

« am: 20. August 2012, 13:40 »

Was gibt es beim Erstellen eines neuen Artikels im Wiki zu beachten? Gibt es eine Seite mit Richtlinien und Hilfestellungen?

52

OS-Design / Re: Kernel malloc/free, kompakt und leichtgewichtig

« am: 18. August 2012, 08:36 »

Ich habe das geschrieben, um eine Umgebung für NetBSD-Treiber bereitzustellen. Wobei alle möglichen allocs, frees und reallocs umgeleitet werden.

Er kann maximal 2x mem_alloc(200000) erfolgreich bedienen, was 0,5 MB Speicher verbraucht. Die freien 31,5 MB können nicht mehr für weitere mem_alloc(200000) verwendet werden.

Deshalb ist das auch eine Speichervewaltung für Test-Kernel. Es ging mir in erster Linie darum Speicher-Bereiche mit der Größe von mehr als einer Seite in möglichst wenig Code bereitzustellen.

Die entsprechenden Artikel im Wiki habe ich mir, neben praktischen Beispielen aus realen Kerneln, angeschaut. Ich hatte gehofft, dass ich einen weiteren Artikel im Wiki hinzufügen könnte.

53

Softwareentwicklung / Re: Archiv in Datei linken

« am: 17. August 2012, 23:55 »

generier ein linkbares Format (wie etwa ELF) oder nimm dd.

54

OS-Design / Kernel malloc/free, kompakt und leichtgewichtig

« am: 17. August 2012, 23:46 »

Diese kompakte und leichtgewichtige Implementierung eines Kernel malloc/free ist aus meinem Treiber-Testkernel und soll der Lowlevel-Community nicht vorenthalten bleiben.

http://pastebin.com/JBcwaTpv

Die Speicherverwaltung weist Speicherblöcke der Größe Seitengröße << n direkt aus dem physischen Speicher zu. Die Seitengröße ist auf 4K festgelegt. In der Standardkonfiguration ist MEMORY_PAGES = 8K, es sind also insgesamt 8K * 4K = 32M für malloc verfügbar. Die Verwaltungsdaten (hier Arrays mit Bitmaps) kommen extra in das data Segment. MEMORY_MEMORY_START_P = 16M bedeutet, dass der Speicherbereich erst ab 16M beginnt und bei MEMORY_MEMORY_END_P = 16M + 32M = 48M endet. Der Bereich darunter (ab 1M) ist also für die text, data und bss Segmente des Kernels

malloc() gibt einen Zeiger auf einen Bereich mit der kleinstmöglichen Speicherklasse zurück. Die Speicherklasse bestimmt die Größe des zugewiesenen Speicherbereichs folgendermaßen: Größe = 1 << Klasse. Die kleinste Klasse ist MEMORY_CLASS_START = 12, da 1 << 12 == MEMORY_PAGE_SIZE == 4K. Die Anzahl unterschiedlicher Speicherklassen wird mit MEMORY_SHIFT_LIMIT = 6 festgelegt. Die größte Klasse (inklusive) ist somit MEMORY_CLASS_END = 12 + 6 = 18.

Wie der Speicher mit MEMORY_SHIFT_LIMIT = 2 und MEMORY_PAGES = 8 aufgeteilt werden würde, zeigt folgendes Beispiel:

0x00000 +---+
        |   | 16x Blöcke der Größe  4K = 64K
        |   |
        |   |
        |   |
0x10000 +---+
        |   |  4x Blöcke der Größe  8K = 32K
        |   |
0x18000 +---+
        |   |  2x Blöcke der Größe 16K = 32K
        |   |
0x20000 +---+

Das Ganze hat dann noch einen Offset von MEMORY_MEMORY_START_P. Die letzte Klasse bekommt dabei einen Slot mehr, da der Platz nun nicht weiter aufgeteilt wird.

Die Referenzen auf printf(), print_str() und halt() müssen in der Umgebung des Kernels aufgelöst werden. Um die Bitmaps zu löschen, muss vor dem ersten malloc() mem_init() ausgeführt werden.

Das Laufzeitverhalten kann verbessert werden, indem freie Slots im Hintergrund gesucht werden. Die Speicherverwaltung weist keine externe Fragmentierung auf und ist weitestgehend robust implementiert, was aber durch Redundanz und/oder Asserts noch gesteigert werden kann.

55

Softwareentwicklung / Re: Wie kann man die Zuverlässigkeit von Software und Computern steigern?

« am: 15. August 2012, 21:21 »

Ich sehe das alles insgesamt recht locker. Weitere Details folgen...

56

Softwareentwicklung / Wie kann man die Zuverlässigkeit von Software und Computern steigern?

« am: 15. August 2012, 14:13 »

Eine nicht vollständige Sammlung von Überlegungen, die Robustheit und Zuverlässigkeit von Software oder auch Hardware zu steigern:

• um durch häufig wiederkehrende Fehler bei der Speicherverwaltung auftretende Verwundbarkeiten zu vermeiden, sollten Maßnahmen ergriffen werden, etwa die zuverlässige Prüfung von Allokations-Details, die Einhaltung der Speichergrenzen und der Zugriffsrechte, sowie das Erkennen von Überläufen .
• bestimmte Algorithmen und Datenstrukturen sind anfälliger für fehlerhafte oder unstimmige Eingabewerte. Die Auswirkungen eines Fehlers sollten sich möglichst lokal auswirken und nicht die gesamte Struktur betreffen.
• der Code bzw. die Schaltung sollte keinen Zustand speichern und vor jedem Aufruf zurückgesetzt werden.
• je einfacher das Design der Architektur und die Implementierung sind, desto nachvollziehbarer ist das System. Dieses kann dann leichter validiert werden, am Besten unabhängig voneinander von mehreren Entwicklern.
• um alle zu erwartenden Kombinationen und Pfade von Daten und Kontrollfluss validieren und die Auswirkung eines eventuellen Fehlers bestimmen zu können sollte deren Anzahl möglichst gering sein.
• neben der Vermeidung resp. Behandlung von DIV-0 und Integer-Overflows sollte die Ausnahmen-Behandlung als besondere Form des Kontrollflusses beachtet werden.
• als String vorliegende Eingabedaten sollten nicht interpretiert werden, so dass diese keinen Einfluss auf den Kontrollfluss haben.
• zwischen nebenläufigem Code sollten keine Abhangigkeiten existieren.
• separate Einheiten sollten so gut es geht isoliert werden und über definierte Schnittstellen mit der Außenwelt kommunizieren. Die Speicherverwaltung sollte den Speicher unterschiedlicher Prozesse voneinander trennen.
• des Weiteren wäre es möglicherweise sinnvoll, ähnliche Maßnahmen redundant auszulegen und neben der Vermeidung auch eine mögliche Kompromittierung erkennen und signalisieren zu können.

Gruß

57

Lowlevel-Coding / Re: VESA Informationen zum Grafikmodus abfragen

« am: 20. June 2012, 19:20 »

Ich habe alle CRT aus meiner Umgebung entfernt.

EDIT: sie sind sperrig und verbrauchen mehr Strom...

58

Lowlevel-Coding / Re: CPU-Reset (Triple Fault) bei Interrupts

« am: 11. June 2012, 09:16 »

Kann auf meinem Android-Device den Code jetzt nicht ganz nachvolliehen, aber Triple Fault kommt, wenn du kein ISR für INT 0x08 (Double Fault) eingerichtet hast. Nach dem STI kommt glaub als erstes ein Timer-Interrupt, wenn du dafür kein ISR hast -> Double Fault -> Triple Fault. Weiss jetz nicht ganz, was du mit gdb genau debuggen willst, wenn es offensichtlich beim STI crasht.

59

Lowlevel-Coding / Re: VESA Informationen zum Grafikmodus abfragen

« am: 09. June 2012, 23:07 »

Die Grafikroutinen erinnern mich an meine ersten Gehversuche in Assembler. Ich war davon begeistert, wie sehr man mit REP MOVSD/STOSD und verschachtelten LOOPs optimieren konnte. Ich bin bis heute kein  Fan von selfmodifying Code auf Maschinencode-Ebene, Farbverläufe mit Dithering... toll

Also Bochs bietet VBE, Vesa Bios Extension, google mal danach.

60

Softwareentwicklung / Re: qemu: fatal: Trying to execute code outside RAM or ROM

« am: 05. June 2012, 15:53 »

OK, gdb info symbol geht auch...