Ellipse statt drei Punkte

content/projekt/HE32/index.md

@@ -17,7 +17,7 @@ Vor einem Vierteljahr habe ich das Buch "The Elements of Computing Systems" (Nis
 wichtig: 2.Auflage!) geschenkt bekommen und die ca. 300 Seiten gleich in einem Rutsch durchgelesen.
 Faszinierend, insbesondere wenn ich mich an mein eher rudimentäres Verständnis meines alten
 Dragon-Books erinnere (dort werden im Wesentlichen die Grundlagen für die Nutzung von
-lex & yacc gelegt - heute: flex & bison). Ich habe damals nach ca. 3/4 des Buches aufgehört ...
+lex & yacc gelegt - heute: flex & bison). Ich habe damals nach ca. 3/4 des Buches aufgehört …
 
 <div class="pure-g">
 {{< image alt="Cover1" src="BookCover.jpg" class="pure-u-1 pure-u-md-1-2" >}}
@@ -97,7 +97,7 @@ vertraut. Hierzu kann der beigestellte VM-Emulator genutzt werden:
 </div>
 
 Als nächstes wird ein Übersetzer erstellt, von VM-Code zu Assembly Language. Wenn man diesen mit dem unter
-2.1 erstellten Assembler kombiniert, kann man also schon von VM-Code direkt in "Native Code" übersetzen ...
+2.1 erstellten Assembler kombiniert, kann man also schon von VM-Code direkt in "Native Code" übersetzen …
 
 ### 2.3 Hochsprache ###
 
@@ -133,7 +133,7 @@ als "Betriebssystem" bezeichnet.
 Interessant ist zum Beispiel das Modul "Memory". Hier schraubt man eine Speicherverwaltung selber zusammen, inkl.
 Garbage Collection Strategie - wirklich lehrreich!
 
-Bei Screen- und Output-Modul befasst man sich mit Bildschirmspeicher und Character-Generierung, wie zu C64-Zeiten ...
+Bei Screen- und Output-Modul befasst man sich mit Bildschirmspeicher und Character-Generierung, wie zu C64-Zeiten …
 
 ## 3. Ein kleines Defizit und dessen Beseitigung ##
 
@@ -155,7 +155,7 @@ Ich habe also alles der Einfachheit halber auf 32-Bit umgestellt, drei Bits einf
 Den bereits existierenden (selbstgeschriebenen) Assembler habe ich um eine Option für die Generierung von diesem
 32-Bit Code erweitert.
 
-Fehlt nur noch eine Testumgebung ...
+Fehlt nur noch eine Testumgebung …
 
 ### 3.2 Becoming a Rustacean ###
 
@@ -164,7 +164,7 @@ verkündet hat, das auch [Rust](https://en.wikipedia.org/wiki/Rust_(programming_
 werden darf, fand ich, das es Zeit ist hier mal nachzurüsten.
 
 **Xperimental**: *Mach lieber [Go](https://en.wikipedia.org/wiki/Go_(programming_language)),
-Rust ist wie C++ (reichlich überladen ...). Hätte ich mal auf ihn gehört!*
+Rust ist wie C++ (reichlich überladen …). Hätte ich mal auf ihn gehört!*
 
 Was mir auch nicht gleich klar war: Rust ist eine funktionale Sprache (wie Scheme, Lisp, Haskell u.ä.), es sieht
 nur optisch wie eine Prozedurale aus.
@@ -181,7 +181,7 @@ auch gleich für eine GUI-Lösung entschieden 🏋 (hier sieht man noch, das die
 ist - nach einiger Web-Recherche habe ich mich für [Qt5 mit ritual](https://rust-qt.github.io/) entschieden).
 
 Eigentlich soll Rust ja "sicher" im Hinblick auf Speicherzugriffe sein, schade auch, das für Qt5 dann große Teile
-wieder auf "unsafe" gedreht werden (müssen) 🖕 ...<br />
+wieder auf "unsafe" gedreht werden (müssen) 🖕 …<br />
 Wenigstens läßt sich der Timer-Event von Qt gut nutzen!<br />
 Nicht so gut funktioniert das Einklinken in die Event-Schleife zwecks Abfangen der Tastatur und Weiterreichung
 an die Emulation (das Symbol wird nicht richtig aufgelöst - ist zumindest nicht auffindbar?!).
@@ -217,9 +217,9 @@ auch in der Realität (externer Speicherzugriff!) ist das SEHR langsam. Hier gil
 
 ## 5. Ausblick ##
 
-Man könnte z.Bsp. mit einer CPU mit mehr Registern (oder auch einem CPU-lokalen Teil-Stack?) experimentieren ... 🤔<br />
+Man könnte z.Bsp. mit einer CPU mit mehr Registern (oder auch einem CPU-lokalen Teil-Stack?) experimentieren … 🤔<br />
 Ebenfalls denkbar: Höherwertige CPU-Befehle (womit wir bei der alten RISC/CISC Diskussion angekommen wären!).<br />
-Man sieht: Der Kurs macht Lust auf mehr ...
+Man sieht: Der Kurs macht Lust auf mehr …
 
 VM: Ein VM-Emulator in Rust wird schneller als die derzeitige Java-Variante sein. Wenigstens ist der mitgelieferte
 VM-Emulator langsamer als HE32, er müsste aber eigentlich schneller sein (wg. der enorm reduzierten Anzahl
@@ -227,4 +227,4 @@ höherwertiger Befehle die sich aber immer noch gut/schnell emulieren lassen).
 
 🗣 Wenn ich ihn richtig verstanden habe, will **Vespasian** eine verbesserte HE32-Version gestützt auf das Tokio-Framework
 entwickeln (oder eine qemu-Version implementieren, die den Assembler-Code wieder auf VM-Code wandelt - oder so ähnlich?).
-Beides um die Performance nochmal richtig zu steigern. Ich bin gespannt ...
+Beides um die Performance nochmal richtig zu steigern. Ich bin gespannt …