Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
41
Das Wiki / Re: PHP Warnungen
« am: 06. April 2017, 00:14 »
Kann bestätigen, Wiki ist derzeit kaputt.
30. May 2023, 20:56
Beiträge anzeigen
Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.
42
Softwareentwicklung / Re: Makefile geteilter Source Code
« am: 03. April 2017, 11:16 »
Make baut Dateien nach gewissen Regeln zusammen. Deine C-Bibliothek ist auch nur eine Datei (klibc.a oder sowas), also kannst du dafür die passenden Regeln definieren. Deine Regel für das Kernel-Binary muss dann nur von dieser Datei abhängen und make wird im Zweifelsfall die libc neu bauen, wenn du den Kernel zusammenbaust.
Du kannst auch abstrakte Ziele (phony targets) definieren, die nicht auf Dateien basieren, in deinem Fall z.B. "libc" und "kernel", wobei der Kernel von der Libc abhängt und "all" vom Kernel (oder von beiden, ist in dem Fall eher egal).
Zu CMake kann ich nichts sagen.
Du kannst auch abstrakte Ziele (phony targets) definieren, die nicht auf Dateien basieren, in deinem Fall z.B. "libc" und "kernel", wobei der Kernel von der Libc abhängt und "all" vom Kernel (oder von beiden, ist in dem Fall eher egal).
Zu CMake kann ich nichts sagen.
43
Softwareentwicklung / Re: Quadratwurzel schnell berechnen
« am: 26. February 2017, 17:20 »
Hast du gemessen oder geschätzt?
44
Softwareentwicklung / Re: Quadratwurzel schnell berechnen
« am: 23. February 2017, 18:25 »
Stimmt, ich dachte an den Mittelwert. War halt spät. 
Die relevante Frage ist, ob das die Anforderungen an Genauigkeit und Geschwindigkeit erfüllt, und das müsste man austesten.
Die relevante Frage ist, ob das die Anforderungen an Genauigkeit und Geschwindigkeit erfüllt, und das müsste man austesten.
45
Softwareentwicklung / Re: Quadratwurzel schnell berechnen
« am: 23. February 2017, 04:49 »Also es geht um das erkennen von komplexen Datenkorrelationen in einem KI-System.Bleibt die Frage, ob du den Definitionsbereich irgendwie eingrenzen kannst, bzw. wo die Genauigkeitsanforderungen am höchsten sind. Deine Erklärung hilft mir da nicht weiter.
Wenn du z.B. weißt, dass deine Werte fast immer klein sind, dann darf die Funktion für große Zahlen auch extreme Werte liefern. Oder du nimmst für große Zahlen die FPU und nur für die kleinen Zahlen eine schnelle Abschätzung per LUT. Ob das für dich praktikabel ist, kann ich nicht einschätzen.
Die geteilte LUT - Funktion wäre die schneller als 50 Takte? Sie müsste ja auch bedingte Sprünge enthalten und Zugriffe auf den Arbeitsspeicher.Keine Ahnung, ob das schneller ist. Mit x86 habe ich nicht so viel zu tun. Mit Sprungvorhersage und einer kleinen, dauerhaft im Cache liegenden LUT sollte das aber nicht weh tun.
Die Interpolation benötigt auch ein paar Rechenoperation auch mul und div, was nicht gerade schnell ist.Nö, das sind nur wenige Befehle (in Pseudo-Assembler, ungetestet):
Code: [Auswählen]
; Ein-/Ausgabe in R1; clobbers R2, R3, R4
LOOKUP:
MOV R4, #LUT ; Pointer zur LUT
SHR R1, R1, #24 ; obere 8 Bit der Eingabe als Tabellenindex (abgerundet)
LD R2, [R4 + R1] ; lade a
INC R1 ; nächster Index
LD R3, [R4 + R1] ; lade b
ADD R1, R2, R3 ; linerare Interpolation ist "(a+b) / 2"
SHR R1, #1 ; kein DIV nötig
Wenn dich die Nichtlinearität für kleine Zahlen stört, musst du für die Indizierung etwas mehr Gehirnschmalz investieren, indem du nicht gleichmäßig verteilst. Da könnte man z.B. mit BSR (Bit Scan Reverse == log base 2) oder CLZ (Count Leading Zeros) arbeiten, um den Index auszurechnen. Bei sowas ist z.B. Excel dein Freund, damit kannst du sowohl die Genauigkeit abschätzen als auch die Tabelle selbst mit generieren.
46
Softwareentwicklung / Re: Quadratwurzel schnell berechnen
« am: 21. February 2017, 02:46 »Exponential /Wurzelfunktionen sind aber stark unter/über-Linear, und wenn man einen Eingangswertebereich von 32-Bit hat was mehr als 4 MRD. sind, wird es schwerDarum schrieb ich, dass du nach Möglichkeit den Definitionsbereich besser eingrenzen solltest.
Nehmen wir mal an, wir nehmen nur jeden tausendsten Wert (immer noch 4 Mio-Werte) in die LUT auf und interpolieren dazwischen, bekommt man rein gar nix mehr Vernünftiges.Du musst die Stützpunkte ja nicht gleichmäßig über den gesamten Definitionsbereich verteilen. Oder du nimmst zwei Tabellen fixer Größe, eine für Zahlen bis 10000 und eine für Zahlen darüber (wo die Nichtlinearität nicht mehr so weh tut).
Es hängt vom Anwendungsfall ab, was praktikabel ist und was nicht, aber darüber schweigst du dich ja netterweise aus...
Ich brauche etwas, dass mir im Schnitt die Wurzel in 10 Takten berechnet, d.h. auf einem 3GHz Rechner 300 Mio. mal pro Sekunde.Das ist reichlich sportlich. Ich rate dir einfach mal, dein Design grundsätzlich darauf abzuklopfen, ob du das Problem nicht anderweitig lösen kannst.
47
Offtopic / Re: Instruction-Length Decoder und Alignment-Unit einer x86 CPU
« am: 20. February 2017, 03:15 »Man könnte den Sequentiellen Decoder stark parallelisieren.Automaten (und der Dekoder ist nichts anderes) sind äußerst schlecht parallelisierbar. Theoretisch könntest du den auch vollständig ausrollen, weil ein Befehl nach maximal 15 Bytes dekodiert ist, aber dann kannst du kein Blockram mehr benutzen. Im Ergebnis wird das nur ein extremer Gatterverhau, für den viel dupliziert werden muss und der durch seine Tiefe gleichzeitig relativ langsam ist.
Also zunächst alle möglichen Prefix-Bytes decodieren und mit einem Shifter das erste Opcodebyte an erster Stelle schieben.Der Hauptvorteil eines byteweise durch den Datenstrom laufenden Dekoders ist, dass ihm das Alignment egal ist. Wenn du damit jetzt nur die Präfixe verarbeiten lässt, verlierst du pro Byte einen Takt und musst den Befehl danach trotzdem neu ausrichten.
Naja, das Problem ist der erste Schritt in dem die Befehlslängen dekodiert werden müssen.Du kannst auch einfach 16 dieser freilaufenden Decoder einfach parallel schalten (mit jeweils einem Byte Versatz) und immer den passenden auswählen.
Die DICache die du beschreibst, ist ja sowas ähnliches wie ne Trace- oder Micro-op Cache.Genau das meinte ich: Du dekodierst auf Teufel komm raus, tust die Ergebnisse in einen Cache und entkoppelst damit den Dekoder vom Prozessor. Außerdem kannst du so relativ einfach mehrere Befehlssätze unterstützen (vgl. ARM/Thumb), solange sie einigermaßen kompatibel sind.
486kb für Cache sollte man nicht unterschätzen.Ich glaube, du unterschätzt den Nutzen von Blockram. Der von mir ursprünglich skizzierte Decoder braucht schonmal mindestens einen Block (bei Xilinx ein RAM36 == 36 KBit, weil dualported). Auch die eine oder andere Pipelinestufe kannst du mit Blockram sparsam und schnell implementieren, statt das in diskrete Logik zu gießen. Gleiches gilt für die Tabellen, die du für trigonometrische Funktionen brauchst, um float/double in hinreichender Genauigkeit zu implementieren. Im Prinzip kannst du auch alles in Logik (Distributed RAM) lösen, aber damit überrennst du das Routingnetz im FPGA und riskierst, dass dein Design nicht mehr synthetisiert (oder nur nach mehreren Tagen).
Wenn ich mir die Liste der Befehle und deine Wunschliste so anschaue, dann wirst du mindestens 2000 Befehle implementieren müssen, vielleicht auch 4000, je nach Zählweise. Ein Großteil davon ist eher unwichtig, muss aber funktionieren (z.B. BCD-Arithmetik, die x87-FPU, der Real Mode), obwohl es kaum benutzt würde. Wenn du solche Befehle in Software (als Mikrocode) implementieren kannst, sparst du dir einerseits extrem viel Fleißarbeit und hast später bessere Stellschrauben, was Größe und Geschwindigkeit angeht. Das ginge dann in die Richtung, was Transmeta vor gut 15 Jahren gemacht hat (allerdings lief das dort mit Unterstützung durch das BIOS).
So ein Mikrocode kostet aber wieder viel Blockram, der nicht für Caches zur Verfügung steht.
48
Offtopic / Re: Instruction-Length Decoder und Alignment-Unit einer x86 CPU
« am: 19. February 2017, 16:48 »
Hi,
naja, dann kann ich dir nicht weiter helfen. Der Befehlssatz wurde für einen sequentiellen Dekoder entworfen, was man an den Prefixbytes deutlich sieht. Die dürfen nämlich in beliebiger Reihenfolge und beliebig oft vorkommen (wobei moderne CPUs ab 16 Bytes Befehlslänge einen #GP werfen), was einen sequentiellen Dekoder nicht weiter stört.
Ich versuch' mal, meinen Ansatz zu retten, obwohl du ihn schon abgelehnt hast.
Wenn du in einem ersten Schritt die Befehlslänge ermittelst, kannst du auch mehrere solcher Dekoder mit jeweils eigenem Offset gleichzeitig laufen lassen und deren Ergebnisse in einer Tabelle, also einem Decoded-Instruction-Cache (DICache) abspeichern. Die Pipeline stallt dann auf dem DICache, nicht auf dem ICache. Am Ende geht es ja nicht darum, die Befehle möglichst schnell zu dekodieren, sondern sie dann dekodiert vorliegen zu haben, wenn du sie brauchst. Es reicht also, wenn du im Mittel schnell genug bist. Intel-Prozessoren führen schon lange keine x86-Befehle mehr direkt aus, also muss dein Core das auch nicht können.
Stellt sich raus, dass dein Dekoder ein Flaschenhals ist, kannst du immernoch an der Anzahl der Decoder drehen. Wirfst du vorne 32 Byte rein (ein einziger beliebig schlecht ausgerichteter Befehl), kannst du vermutlich im Schnitt acht Dekoder voll auslasten und hättest nach Sprüngen nur wenig zusätzliche Latenz. Gegenüber einem Cache Miss fällt das überhaupt nicht ins Gewicht (und mit dem bisschen integriertem RAM - der größte Cyclone IV hat 486 KB - bekommst du keine großen Caches hin). Sehr kurze Schleifen könntest du aber aus dem DICache versorgen.
Gruß,
Svenska
naja, dann kann ich dir nicht weiter helfen. Der Befehlssatz wurde für einen sequentiellen Dekoder entworfen, was man an den Prefixbytes deutlich sieht. Die dürfen nämlich in beliebiger Reihenfolge und beliebig oft vorkommen (wobei moderne CPUs ab 16 Bytes Befehlslänge einen #GP werfen), was einen sequentiellen Dekoder nicht weiter stört.
Ich versuch' mal, meinen Ansatz zu retten, obwohl du ihn schon abgelehnt hast.
Wenn du in einem ersten Schritt die Befehlslänge ermittelst, kannst du auch mehrere solcher Dekoder mit jeweils eigenem Offset gleichzeitig laufen lassen und deren Ergebnisse in einer Tabelle, also einem Decoded-Instruction-Cache (DICache) abspeichern. Die Pipeline stallt dann auf dem DICache, nicht auf dem ICache. Am Ende geht es ja nicht darum, die Befehle möglichst schnell zu dekodieren, sondern sie dann dekodiert vorliegen zu haben, wenn du sie brauchst. Es reicht also, wenn du im Mittel schnell genug bist. Intel-Prozessoren führen schon lange keine x86-Befehle mehr direkt aus, also muss dein Core das auch nicht können.
Stellt sich raus, dass dein Dekoder ein Flaschenhals ist, kannst du immernoch an der Anzahl der Decoder drehen. Wirfst du vorne 32 Byte rein (ein einziger beliebig schlecht ausgerichteter Befehl), kannst du vermutlich im Schnitt acht Dekoder voll auslasten und hättest nach Sprüngen nur wenig zusätzliche Latenz. Gegenüber einem Cache Miss fällt das überhaupt nicht ins Gewicht (und mit dem bisschen integriertem RAM - der größte Cyclone IV hat 486 KB - bekommst du keine großen Caches hin). Sehr kurze Schleifen könntest du aber aus dem DICache versorgen.
Gruß,
Svenska
49
Offtopic / Re: Instruction-Length Decoder und Alignment-Unit einer x86 CPU
« am: 19. February 2017, 02:00 »
Hi,
die Kombination aus "AMD64 + sämtliches SSE + VT-X", "Out-Of-Order und superskalar", "relativ wenig Logik" und "relativ schnell" halte ich für einen nicht erfüllbaren Widerspruch. RISC-V ist deutlich einfacher zu dekodieren, und die Implementationen (sowohl die von Berkeley als auch andere) unterscheiden sich doch ziemlich massiv in Ressourcenverbrauch und erreichbarer Taktfrequenz. Eine 100 MHz schnelle Out-of-Order-Architektur mit IPC > 1 ist schon da echt sportlich. Zum Vergleich: Der Core, den ich verwende (PicoRV32), läuft zwar mit bis zu 275 MHz, ist aber nur In-Order mit einem IPC von etwa 0,3.
Mit den Patenten und den Ansätzen befasse ich mich jetzt nicht, sondern gebe eine weitere Idee. Die Alignment-Unit kannst du mit einem Dual-Ported BRAM mit einem byteweisen Ausgabeport nachbilden. Bei Sprüngen musst du dann nur den Offset beim Zugriff draufaddieren und bekommst einen Bytestrom. Den kannst du klassisch durch eine FSM dekodieren, was natürlich mehrere Takte (einen Takt pro Byte) dauert. Da du aber einen FPGA hast, kannst du den Dekoder in eine eigene, schnell laufende Taktdomäne legen (vermutlich musst du den Teil dann ziemlich massiv constrainen, damit das performt, aber es spart gut Logik).
Der Dekoder würde pro Takt ein Byte dekodieren, muss also für zweifache Superskalarität und einer durchschnittlichen Instruktionslänge von 3 (vgl. Quelle) sechsmal so schnell laufen wie der Core selbst. Bei geschätzten 200 MHz Dekodertaktrate und 40 MHz Kerntaktrate passt das einigermaßen zusammen.
Gruß,
Svenska
die Kombination aus "AMD64 + sämtliches SSE + VT-X", "Out-Of-Order und superskalar", "relativ wenig Logik" und "relativ schnell" halte ich für einen nicht erfüllbaren Widerspruch. RISC-V ist deutlich einfacher zu dekodieren, und die Implementationen (sowohl die von Berkeley als auch andere) unterscheiden sich doch ziemlich massiv in Ressourcenverbrauch und erreichbarer Taktfrequenz. Eine 100 MHz schnelle Out-of-Order-Architektur mit IPC > 1 ist schon da echt sportlich. Zum Vergleich: Der Core, den ich verwende (PicoRV32), läuft zwar mit bis zu 275 MHz, ist aber nur In-Order mit einem IPC von etwa 0,3.
Mit den Patenten und den Ansätzen befasse ich mich jetzt nicht, sondern gebe eine weitere Idee. Die Alignment-Unit kannst du mit einem Dual-Ported BRAM mit einem byteweisen Ausgabeport nachbilden. Bei Sprüngen musst du dann nur den Offset beim Zugriff draufaddieren und bekommst einen Bytestrom. Den kannst du klassisch durch eine FSM dekodieren, was natürlich mehrere Takte (einen Takt pro Byte) dauert. Da du aber einen FPGA hast, kannst du den Dekoder in eine eigene, schnell laufende Taktdomäne legen (vermutlich musst du den Teil dann ziemlich massiv constrainen, damit das performt, aber es spart gut Logik).
Der Dekoder würde pro Takt ein Byte dekodieren, muss also für zweifache Superskalarität und einer durchschnittlichen Instruktionslänge von 3 (vgl. Quelle) sechsmal so schnell laufen wie der Core selbst. Bei geschätzten 200 MHz Dekodertaktrate und 40 MHz Kerntaktrate passt das einigermaßen zusammen.
Gruß,
Svenska
50
Softwareentwicklung / Re: Quadratwurzel schnell berechnen
« am: 19. February 2017, 00:55 »naja das iterationsverfahren muss schon 3 bis 4 mal durchgeführt werdenNaja, das Quake3-Verfahren (berechnet allerdings die Inverse und als Float) nutzt einen geschickten Anfangswert und kommt daher mit nur einer Iteration aus.
Das sind einige Maschinenbefehle die da durchgejagt werden müssen. Blöderweise auch Divisionen die relativ langsam sind. Das wird dann langsamer als gleich die FPU zu bemühen.Auf modernen Maschinen ist die Anzahl der Instruktionen nicht unbedingt ein guter Indikator für die Gesamtgeschwindigkeit.
Wenn du den Definitionsbereich besser eingrenzen kannst, wäre vielleicht eine Tabelle (mit linerarer Interpolation) was für dich. Auf kleinen Mikrocontrollern erschlägt man die meisten komplexen Funktionen (sin, log, e^x) mit solchen Ansätzen.
51
Lowlevel-Coding / Re: VESA Grafik-Modi
« am: 11. February 2017, 22:05 »Und da habe ich als Maximalwert mit einer MSI_PCIe Grafikkarte eben diese 130 Millionen Pixel Schreibgeschwindigkeit gemessen.Mit einem VESA-Treiber? Da bin ich jetzt aber erstaunt (bei angenommenen 32 Bit-Pixeln sind das stolze 520 MB/s).
Es würde aber Sinn machen, wenn man Speicherbereiche innerhalb des Grafikkarten-RAMS verschieben könnte. [...] Aber leider weiß ich nicht wie das gehen könnte...Wie ich bereits schrieb, ist der Blitter ein Grundbestandteil jeder Grafikkarte mit eingebautem 2D-Beschleuniger (und im Gegensatz zur CPU bezahlt der Blitter auch keine Zinsen, um das VRAM zu lesen). Um ihn zu nutzen, brauchst du aber einen nativen Treiber.
Ein klassischer 2D-Beschleuniger ist IBMs 8514/A, der auch die Grundlage für ATIs frühe Karten (Mach und Rage) bildet. Vielleicht findet man in modernen AMD-Karten noch Kompatiblitätsreste dafür, aber das wäre trotzdem herstellerspezifisch. Und dein Problem mit dem Modesetting löst es trotzdem nicht.
52
Lowlevel-Coding / Re: VESA Grafik-Modi
« am: 08. February 2017, 01:40 »Geschwindigkeit ist da, je nach Grafikkarte, von 8 Mio-Pixel bis 130 Mio-Pixel in der Sekunde.Ich weiß jetzt nicht, wo du deine Zahlen her hast (Megapixel pro Sekunde klingt für mich eher nach einer 3D-Rendereinheit oder so), aber mit 8 MB/s Bandbreite kommst du bei 1024x768x32 auf 3 fps, bei höherer Auflösung entsprechend weniger. Damit macht selbst zweidimensionales Fenster-mit-Inhalt-Verschieben keinen Spaß.
Die einzige sinnvolle Grafikbeschleunigung wäre ein Pixelblitter der mir komplette Speicherbereiche vom RAM in den Grafikspeicher verschiebt, aber so was scheints nicht zu geben, oder?Ein Blitter kopiert normalerweise nur zweidimensionale Strukturen innerhalb des Grafikspeichers und ist in jedem 2D-Beschleuniger drin. Du meinst eine DMA-Engine, die in jeder 3D-fähigen Grafikkarte drin sein sollte. Beides braucht aber native Treiber.
Wenn man den Schreibzugriff auf den VRAM hinreichend schnell bekommt, bekommt man auch mit VESA einigermaßen gebrauchbare Performance (für hinreichend leistungsfähige CPU) hin, indem man eine Kopie des Bildes im normalen RAM hält, Veränderungen dort unterbringt und nur die geänderten Passagen ins VRAM schreibt. Für Vollbildvideo mit 25 fps reicht das aber trotzdem nicht.
Außerdem löst es dein Problem mit der falschen Auflösung trotzdem nicht. Dazu brauchst du einen nativen Grafiktreiber, eine andere Grafikkarte oder - mit Glück - nur einen anderen Bildschirm.
53
Lowlevel-Coding / Re: VESA Grafik-Modi
« am: 04. February 2017, 00:20 »
Praktisch muss ein VESA-BIOS nur 640x480 und 1024x768 mit mindestens 256 Farben unterstützen. Sämtliche anderen Modi wurden von modernen Betriebssystemen überhaupt nur als Fallback-Lösungen benutzt, bis ein nativer Treiber vorhanden ist. Für geringe Auflösungen und Textmodi reicht ein nativer VGA/CGA-Treiber.
An sich ist VESA nur ein historisches Artefakt der 90er, damit DOS-Spiele herstellerübergreifend ein paar höhere Auflösungen benutzen konnten. Abgesehen von Systemtools und Bootloadern gibt es keinen für die Hersteller relevanten Nutzer dieser Technologie mehr (denen ist die exakte Auflösung egal) und mit UEFI kann man es nicht benutzen.
Modesetting ist ein schwieriges Problem, was selbst moderne Grafiktreiber vor Schwierigkeiten stellt. Da will man nicht den gleichen Aufwand nur für eine Schnittstelle treiben, die nahezu niemand benutzt. Daher gibt es nur eine Basisunterstützung. Außerdem ist ein VESA-Treiber unbeschleunigt und daher langsam - teilweise auch sehr langsam.
An sich ist VESA nur ein historisches Artefakt der 90er, damit DOS-Spiele herstellerübergreifend ein paar höhere Auflösungen benutzen konnten. Abgesehen von Systemtools und Bootloadern gibt es keinen für die Hersteller relevanten Nutzer dieser Technologie mehr (denen ist die exakte Auflösung egal) und mit UEFI kann man es nicht benutzen.
Modesetting ist ein schwieriges Problem, was selbst moderne Grafiktreiber vor Schwierigkeiten stellt. Da will man nicht den gleichen Aufwand nur für eine Schnittstelle treiben, die nahezu niemand benutzt. Daher gibt es nur eine Basisunterstützung. Außerdem ist ein VESA-Treiber unbeschleunigt und daher langsam - teilweise auch sehr langsam.
54
Lowlevel-Coding / Re: VESA Grafik-Modi
« am: 20. January 2017, 02:09 »
Sämtliche VESA-Funktionalität läuft über das in der Grafikkarte verbaute Video-BIOS (VBIOS). Wenn ein Grafikmodus vom VBIOS nicht angeboten wird, dann kannst du ihn nicht mit einem VESA-Treiber benutzen. Fertig.
55
Softwareentwicklung / Re: Eigene Programmiersprache
« am: 06. January 2017, 03:42 »
Naja, wenn es dir allein um den Parser geht, kannst du auch gleich die übliche Konvention von vielen Assemblersprachen benutzen. Das macht es jedenfalls einfacher, in die Sprache einzusteigen (weil es dann für dein Einstieg nur ein High-Level-Assembler ist und keine eigene Sprache). Bei kleinen ARMs gibt es z.B. #4 (Immediate), R1 (Wert), [R2] (Dereferenzierung) und ein paar für dich eher uninteressantere Varianten. Die Unix-Welt fällt da etwas raus, die finde ich persönlich auch deutlich schlechter lesbar.
Ansonsten ist deine Sprache halt schlicht ein kleiner Assembler, ganz nett. Wenn du ein paar Programme damit geschrieben hast (also jenseits von Hallo-Welt), dann weißt du schon, was ganz gut funktioniert und was total scheiße ist.
Die Runtime ist eigentlich viel wichtiger als die Kernsprache (und die Entscheidung, was in die Runtime gehört und was nicht). Davon hängt ab, was du überhaupt machen kannst und wie gut bestimmte Dinge funktionieren.
Zum Parser gibt's eigentlich nur zu sagen, dass man den zwar handklopfen kann, aber nicht muss. Zu lex und yacc gibt es sicher auch deutsche Tutorials, wenn du dir das auf Englisch nicht antun möchtest, aber das sind klassische Ansätze dazu. Damit kannst du deiner Sprache eine deutlich mächtigere Grammatik geben - und eine ordentliche Syntaxprüfung (aber keine ordentlichen Fehlermeldungen, das bleibt dann bei "syntax error in line 42").
Ansonsten ist deine Sprache halt schlicht ein kleiner Assembler, ganz nett. Wenn du ein paar Programme damit geschrieben hast (also jenseits von Hallo-Welt), dann weißt du schon, was ganz gut funktioniert und was total scheiße ist.
Die Runtime ist eigentlich viel wichtiger als die Kernsprache (und die Entscheidung, was in die Runtime gehört und was nicht). Davon hängt ab, was du überhaupt machen kannst und wie gut bestimmte Dinge funktionieren.
Zum Parser gibt's eigentlich nur zu sagen, dass man den zwar handklopfen kann, aber nicht muss. Zu lex und yacc gibt es sicher auch deutsche Tutorials, wenn du dir das auf Englisch nicht antun möchtest, aber das sind klassische Ansätze dazu. Damit kannst du deiner Sprache eine deutlich mächtigere Grammatik geben - und eine ordentliche Syntaxprüfung (aber keine ordentlichen Fehlermeldungen, das bleibt dann bei "syntax error in line 42").
56
Softwareentwicklung / Re: Eigene Programmiersprache
« am: 31. December 2016, 00:12 »Das letzte Update habe ich gerade eben hochgeladen und eine Dokumentation sowie Beispielcode ist auch verfügbar.Das ist aber lieb. Magst du uns auch verraten, wohin und wo?
Wenn ich an Assembler denke, habe ich immer eine Low-Level-Umgebung (Mikrocontroller, Startup-Code o.ä.) im Hinterkopf. Von daher stellt sich bei mir direkt die Frage, ob say, inp oder prv Basisbefehle oder ein Teil der Runtime sind. Irgendwo vorher käme noch die Frage, ob es eine Runtime gibt, wie groß sie (in etwa) ist und was sie kann.
Ein paar andere Fragen fallen mir spontan ein, aber da könnte die Dokumentation helfen. Sowas wie:
- Warum schreibst du Immediates in eckige Klammern? (ARM- und x86-(Intel-)Assembler nutzen das für Dereferenzierung.)
- Warum hast du einen Funktionskopf, aber zwei Funktionsenden (end und endf)?
- Welche Datentypen gibt es (ich sehe "int" und "konstanter String", echte Strings wären interessant)?
- Fehlt in der zweiten Zeile zufällig ein Semikolon?
57
Lowlevel-Coding / Re: performancecounter frequenz bzw. CPU-Takt
« am: 02. December 2016, 22:36 »
Der TSC zählt nur Takte, der weiß nicht, wie schnell die kommen und kann dir das darum nicht verraten. Du kannst ihn aber einmalig mit einem richtigen Timer abgleichen und solange du nichts seltsames mit der CPU anstellst (kein idle, kein frequency scaling), innerhalb eines Cores bleibst und das BIOS die CPU nicht wegen Überhitzung bremst, kannst du damit auch eine gute, kurze Zeit-Warteschleife realisieren.
Für alles andere solltest du den HPET oder PIT benutzen.
Für alles andere solltest du den HPET oder PIT benutzen.
58
Lowlevel-Coding / Re: performancecounter frequenz bzw. CPU-Takt
« am: 26. November 2016, 06:30 »
Um die momentane mittlere Frequenz des TSC herauszubekommen, brauchst du eine zuverlässige (Zeit-)Referenz. Die bekommst du vom HPET (oder notfalls vom PIT), denn deren Grundtakt ist festgelegt. Du baust dir also eine Warteschleife bekannter Zeit (z.B. 10 ms) und liest vorher und nachher den TSC aus. Aus der Differenz kannst du die Schritte pro Sekunde und damit die Frequenz ableiten. Für gebrauchbare Ergebnisse sollte die Warteschleife Busy-Waiting ohne aktive Interrupts durchführen.
Die wahre CPU-Frequenz bekommst du über ACPI, aber das ist viel Arbeit.
Bedenke, dass der TSC keine stabile Zeitbasis ist. Es hängt von der konkreten Architektur ab, was er genau tut. Manchmal skaliert der TSC mit der CPU-Frequenz, manchmal nicht. Manchmal bleibt er im Idle stehen. Manchmal sind die TSCs mehrerer Cores auf einem Die synchronisiert, manchmal laufen sie auseinander. Manchmal sogar dann, wenn die Cores mit der gleichen Geschwindigkeit laufen.
Die wahre CPU-Frequenz bekommst du über ACPI, aber das ist viel Arbeit.
Bedenke, dass der TSC keine stabile Zeitbasis ist. Es hängt von der konkreten Architektur ab, was er genau tut. Manchmal skaliert der TSC mit der CPU-Frequenz, manchmal nicht. Manchmal bleibt er im Idle stehen. Manchmal sind die TSCs mehrerer Cores auf einem Die synchronisiert, manchmal laufen sie auseinander. Manchmal sogar dann, wenn die Cores mit der gleichen Geschwindigkeit laufen.
59
Lowlevel-Coding / Re: Ablauf Paging
« am: 11. November 2016, 23:39 »
Ja, das hatte ich so praktisch ausprobiert. Mir ging es auch nicht darum, irgendwelche Informationen aus gdb rauszukitzeln (kann ich sowieso nicht), sondern nur darum, Qemu zum richtigen Zeitpunkt anzuhalten.
Und das war genau der Zeitpunkt zwischen "schreibe CR0 mit aktivem PG" und "führe die folgende Instruktion aus". Damit hatte ich Qemu dann in einem Zustand, wo "info tlb" funktioniert, aber der Triple-Fault-Reset noch nicht zuschlägt, und da habe ich dann auch den Bug gefunden. Was es genau war, weiß ich nicht mehr, aber im Monitor war offensichtlich, was falsch war.
Endlosschleifen funktionieren nur, wenn sie auch tatsächlich ausgeführt werden können. In meinem Fall ging das nicht und das Qemu-Log war auch nicht hilfreich, weil die Adressen auch alle stimmten.
Und das war genau der Zeitpunkt zwischen "schreibe CR0 mit aktivem PG" und "führe die folgende Instruktion aus". Damit hatte ich Qemu dann in einem Zustand, wo "info tlb" funktioniert, aber der Triple-Fault-Reset noch nicht zuschlägt, und da habe ich dann auch den Bug gefunden. Was es genau war, weiß ich nicht mehr, aber im Monitor war offensichtlich, was falsch war.
Endlosschleifen funktionieren nur, wenn sie auch tatsächlich ausgeführt werden können. In meinem Fall ging das nicht und das Qemu-Log war auch nicht hilfreich, weil die Adressen auch alle stimmten.
60
Lowlevel-Coding / Re: Ablauf Paging
« am: 11. November 2016, 02:14 »
Im Qemu-Monitor waren zumindest für mich immer "info tlb" und "info mem" hilfreich, denn das zeigt dir immerhin an, was Qemu von deinem Code verstanden. Dafür muss Paging aber aktiv sein.
Du kannst einen GDB an deinen Kernel anflanschen, einen Breakpoint auf deinen "setze das PG-Bit"-Befehl setzen und dann genau einen Single-Step machen. In dem Augenblick ist Paging aktiv, aber der Triple-Fault noch nicht geschehen, und dann kannst du dir das Chaos im Monitor anschauen. Eventuell siehst du dann, was du falsch machst.
Du kannst einen GDB an deinen Kernel anflanschen, einen Breakpoint auf deinen "setze das PG-Bit"-Befehl setzen und dann genau einen Single-Step machen. In dem Augenblick ist Paging aktiv, aber der Triple-Fault noch nicht geschehen, und dann kannst du dir das Chaos im Monitor anschauen. Eventuell siehst du dann, was du falsch machst.