Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Reuther Newsgroups: de.alt.folklore.computer Subject: Re: Acorn Archimedes Date: Thu, 30 Jan 2025 18:21:05 +0100 Lines: 85 Message-ID: References: <1r6ks8s.yif8ig1psz6umN@ID-7682.user.dfncis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net O2R2qXOlOzbLsg2bEovxAAiKXoyAcE5MvuGOOJY0fpVpPAfhWd Cancel-Lock: sha1:QcR67hgEBAwDy5p57iEZvXtNKZQ= sha256:Jp5IIouD3rVaEMim2lya0QPUHcxpJ8u9oqHMNtSnMSs= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 Hamster/2.1.0.1538 In-Reply-To: Xref: csiph.com de.alt.folklore.computer:47329 Am 29.01.2025 um 22:00 schrieb Thomas Koenig: > Stefan Reuther schrieb: >> Am 28.01.2025 um 22:03 schrieb Thomas Koenig: >>> Die Archektur hat alle Instruktionen als Vielfaches von vier Bytes. >>> Immediates, die nicht in die 5-bit-Register passen, sind entweder >>> 32 oder 64 Bytes groß. >> [...] >>> Das ist in einem ziemlich ausgeklügelten Encoding reingepackt. >>> Um die Länge einer Instruktion zu dekodieren (also nachzuschauen, >>> wo die nächste Instruktion anfängt) werden 33 Gates benötigt, >>> maximal 3-Eingänge NOR oder NAND, in vier Ebenen verschaltet, >>> also vier Gate Delays. >> >> Das ist durchaus weniger komplex als bei Intel, aber das Problem, dass >> eine Instruktion dann viele Cache Misses, TLB Misses und Page Faults >> auslösen kann, bleibt damit. > > Wir sind in dem Zeitalter angekommen, wo man für eine 64-bit-Architektur > eine minimale Cache-Line-Größe vorschreiben kann :-) > > Mit 64 Bytes dache line kann eine Instrukion von maximal 20 > Bytes dann höchstens einen Cache Miss auslösen. ...und dazu noch TLB Misses und Page Faults, sowie die von dem in der Instruktion enthaltenen Speicherzugriff enthaltenen Datum. Das schlägt dann bis auf die Software durch, die dann aufpassen muss, jene Page/TLB-Einträge nicht zu löschen, um Fortschritt gewährleisten zu können. Kein unlösbares Problem, aber eben dennoch eine Entscheidung, die ich in der Form nicht treffen würde, wenn meine Mission "Einfachheit" lautet. >> Die ständig erweiterte ISA ist ein Problem. Aber push und pop sind in >> erster Linie auch nichts anderes als Store mit Prädekrement/ >> Postdekrement, was jeder RISC hat. Oder wo siehst du da ein Problem? > > Wenn man das naiv macht, rennt man in Hazards bei Pipelines. > > Nehmen wir mal > > pushq %r14 > pushq %r15 > > Das ist, ausgeschrieben, > > leaq -8(%rsp),%rsp > movq %r14,(%rsp) > leaq -8(%rsp),%rsp > movq %r15,(%rsp) > > Das ist ein read-after-write Hazard - ich kann das zweite subq erst > ausführen, wenn ich das Resultat des ersten habe, d.h. man müsste > da erst mal warten, bis der fertig ist. Das ist bei einer OoO - > Implementierung, bei der gleichzeitig viel Instruktionen parallel > laufen, sehr ärgerlich. Das Problem hat ARM bei 'push r0' aka 'str r0, [sp, #-4]!' ebenso. Und jede andere RISC-Architektur auch. Also kein Vorwurf, den man x86 oder amd64 machen könnte. > Bei aarch64 wäre das ein add auf den Stackpointer und ein stp > (Store Pair), also acht Bytes, und einen ganzen Sack Komplikationen > weniger. Würdest du das so machen, hättest du wieder den möglichen Hazard beim 'add', und das 'stp' löst dir nur den Spezialfall, dass du genau zwei Register hast, die m.W. auch noch benachbart sein müssen. Praktisch vermeiden Compiler offenbar heutzutage push/pop, sondern legen die Stackframes bereits mit entsprechend Platz an und nutzen dann entsprechend SP- oder FP-relative Adressierung, und zwar sowohl bei ARM, als auch bei amd64. >> Spaßig ist sowas wie "pop ss" (macht für die nächste Instruktion *alle* >> Interrupts zu inkl. NMI), aber das ist in amd64 hoffentlich kein Thema >> mehr... > > *schauder* Das ist halt nötig, damit es zuverlässig funktioniert, denn wenn der Interrupt zuschlägt, während du gerade die Hälfte der Stack-Adresse geladen hast, versaut dir das ganz schön den Tag. Stefan