Mehrere Threads Anhalten/Weiterführen

hustbaer

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

Nicht zu vergessen, dass auf heutigen Rechnern unter deinem Betriebssystem Minimum noch zwei weitere laufen. Einmal 1,5 Betriebssysteme, die wir salopp UEFI nennen. Dann ein weiteres im Platform Supportcode, AGESA auf AMD und Minix auf Intel.

Also so wie ich das verstehe läuft MINIX nicht unter sondern neben dem OS. Auf eigenen Cores, die Teil des Chipset sind. Das sollte die Echtzeitfähigkeit des Haupt-Systems nicht wirklich beeinflussen.

hustbaer

@Enumerator
Auf Windows sollte ein 10ms Takt mit "soft realtime" Anforderung drin sein. Kommt halt drauf an wie viele "Aussetzer" pro Stunde man tolerieren kann. Wenn du nichtmal einen Aussetzer pro Tag tolerieren kannst, dann vermutlich eher nicht. Wenn 2-3 Aussetzer pro Stunde OK sind, dann sollte das gehen. Kommt aber wirklich auf die Hardware/Treiber an. Nur: wenn die nicht mitspielen, dann kannst du da auch mit SuspendThread & Co nix mehr machen.

Und wenn Hardware & Treiber mitspielen, dann sollte es auf Windows gut reichen die Prozess- und Thread-Priorität hochzusetzen.

Auf Linux: keine Ahnung. Die "niceness" funktioniert ganz anders als die relativ harten Thread-Prioritäten von Windows.

VLSI_Akiko

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Ein weiterer Störfaktor unterhalb der OS- und oberhalb der Programmebene kann übrigens auch noch der Garbage Collector bei Java-VM oder .NET-Sprachen sein. Das habe ich schon bei einigen Spielen bewundern dürfen, die z.B. in einer .NET-Sprache geschreiben wuren (z.B. mit Unity Engine). Da ist in der Standardinstallation nicht selten tatsächlich so ein "Stop-the-World"-GC aktiv der in ungünstigen Konstellationen das Spiel tatsächlich im regelmässigen Takt teilweise bis zu 2 Sekunden einfrieren lässt.

Ohhh ja, ich erkläre seit Jahrzenten, dass Sprachen mit einem GC ganz nett sind, aber für Anwendungen, wo es auf relativ genaues Timing ankommt, absolutes Gift sind. Du weißt einfach nie, wann ein GC loslegt und dann irgendwo Bandbreite im RAM oder CPU Zeit frisst, die du gerade feindosiert brauchst. Wohl gemerkt, Sprachen bei denen man wenig bis keine Kontrolle über den GC hat. "Ja aber Akiko, du hast so dafür keine Memoryleaks!" Wowowow ... dann schau doch mal das tolle Spiel Oxygen not Included an. Lade einen 300+ Runden Spielestand etwa 50 mal. Wenn dann das Spiel noch unter 64 GB RAM frisst, haste Glück gehabt.

Extrem nervig als Spieler - ich frage mich, ob es da keinen besseren GC gibt, der vielleicht arbeitsintensiver ist, dafür aber diskret im Hintergund arbeitet ohne alles zu stoppen.

Da bin ich mir nicht sicher. Theoretisch hat man es besser im Griff in Sprachen wo man den GC instruieren kann, sprich den GC anweisen kann, wann und wie lange er aufräumen darf. Eine der besten Lösungen ist aber nach wie vor das RAII, wie man es in C++ und Ada direkt steuern kann, oder in funktionalen Sprachen wie R oder ML bzw in modernen Sprachen wie Rust implizit hat. Sprich ein Freigeben von Speicher findet immer dann statt, wenn ein Objekt abgebaut wird, und dass ist etwas was man relativ gut kontrollieren kann.

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Also so wie ich das verstehe läuft MINIX nicht unter sondern neben dem OS. Auf eigenen Cores, die Teil des Chipset sind. Das sollte die Echtzeitfähigkeit des Haupt-Systems nicht wirklich beeinflussen.

Ja okay, ist wohl irgendwo eine Interpretationsfrage. Also ich definiere "unter" als völlig transparent zum Hauptbetriebssystem. Oder man kann auch schauen, wer bekommt Priorität beim Zugriff auf die Hardware (Remotezugriff auf Managementsysteme)

Habe ich auch immer gedacht, dass es nichts ausmach, bis ich an einem embedded Systemen gearbeitet habe, dass 24/7 kontinuierlich 96kHz/18Bit/8 Kanäle und parallel dazu drei Serialport Streams (2x 115200, 1x 19200 Baud) Signalanalyse gemacht hat. Da gabs eine leichte Varianz bei der PCI Latenz und die wurde von einem dieser Betriebssysteme im Platform Supportcode verursacht.

hustbaer

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

Ja okay, ist wohl irgendwo eine Interpretationsfrage. Also ich definiere "unter" als völlig transparent zum Hauptbetriebssystem. Oder man kann auch schauen, wer bekommt Priorität beim Zugriff auf die Hardware (Remotezugriff auf Managementsysteme)

Ja, verstehe. Ich hab "unter" halt im Sinn von einem Hypervisor interpretert, und so ist es eben soweit ich weiss nicht.

Habe ich auch immer gedacht, dass es nichts ausmach, bis ich an einem embedded Systemen gearbeitet habe, dass 24/7 kontinuierlich 96kHz/18Bit/8 Kanäle und parallel dazu drei Serialport Streams (2x 115200, 1x 19200 Baud) Signalanalyse gemacht hat. Da gabs eine leichte Varianz bei der PCI Latenz und die wurde von einem dieser Betriebssysteme im Platform Supportcode verursacht.

Interessant!
Aber natürlich muss das Management-System irgendwie Zugriff auf die Hardware haben, es soll sie ja schliesslich überwachen. D.h. leichte Timing-Unterschiede auf diversen Bussen etc. werden leider nicht zu vermeiden sein. Ausser wenn man das Management-System abdreht - wenn es sich denn abdrehen lässt.

Ich finde diese Management-System auch grundsätzlich ziemlich cool. Wenn man so richtig viele (physikalische) Server hat, ist man schon froh, wenn man einfach nur in einem Admin-Tool klicksi machen muss und damit z.B. einen Server der hängt "hart" rebooten kann. Oder ausschalten/einschalten/was auch immer man braucht. Blöd ist nur wenn sie sich eben nicht abdrehen lassen, und dann (wenn auch nur geringfügig) das System stören. Oder natürlich wenn sie Sicherheitslücken in z.B. ihrem Netzwerk-Stack haben.

VLSI_Akiko

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

Ja okay, ist wohl irgendwo eine Interpretationsfrage. Also ich definiere "unter" als völlig transparent zum Hauptbetriebssystem. Oder man kann auch schauen, wer bekommt Priorität beim Zugriff auf die Hardware (Remotezugriff auf Managementsysteme)

Ja, verstehe. Ich hab "unter" halt im Sinn von einem Hypervisor interpretert, und so ist es eben soweit ich weiss nicht.

Wobei es einen Hypervisor ja nicht ausschließt, ein guter Hypervisor wird auch von dem darin laufenden Betriebssystem nicht bemerkt. Pass auf, es wird noch unangenehmer. Wenn man baremetal programming macht oder eben Betriebssysteme/Bootloader schreibt, arbeitet man ja mit den verschiedenen Hardwarezugriffsleveln der CPU. Bei x86 wäre das Ring 0 bis 3, beim m68k usermode und supervisormode, bei ARM usermode, kernelmode und trustzone/trusted mode und so weiter. Dadurch dass Intel einige ihrer Platform Supportcode Geschichten ja so dermaßen vergeigt haben, dass da mehrere kritische Updates nötig waren und einige Entwickler die ganze Geschichte anfangen konnten zu reverse-engineeren (siehe Coreboot/Libreboot, die können den Platform Supportcode teilweise ersetzen/deaktivieren), kam raus, dass x86 CPUs in der Tat noch einen Ring -1 bis Ring -3 haben. Es war viele Jahre lang unbekannt. Dies ist nicht nur gruselig, es ist im höchsten Maße bedenklich. Man kann vor allem diese Accesslevel nicht in den Bitmasken in den global describer tables setzen und irgendwie nutzen. Falls du dich fragst wo das Verwendung findet. Die Virtualisierungshardware Vanderpool (Intel) und Pacifica (AMD) sind keine reine Hardwarelösung, sondern ein Hypervisor, der im Ring -1 läuft. Im Ring -2 läuft die Systemmanagementsoftware und Ring -3 ist nicht mal die eigentlich x86 CPU, sondern der eingebettete Kern (ARC oder 80586) der seine Geschichten macht. Ist jedenfalls mein aktueller Kentnissstand. Im Großen und Ganzen hast du erstaunlich wenig Kontrolle über deine x86 Hardware. Bei ARM ist es zum Beispiel nicht ganz so schmlimm. Auf Github findest du die ARM Trusted Firmware, welche die Software ist, die in der Trustzone läuft. Ist allerdings nicht bei jedem ARM so realsiert (RPi zum Beispiel, der ist mehr locked-down als andere ARM Lösungen).

Habe ich auch immer gedacht, dass es nichts ausmach, bis ich an einem embedded Systemen gearbeitet habe, dass 24/7 kontinuierlich 96kHz/18Bit/8 Kanäle und parallel dazu drei Serialport Streams (2x 115200, 1x 19200 Baud) Signalanalyse gemacht hat. Da gabs eine leichte Varianz bei der PCI Latenz und die wurde von einem dieser Betriebssysteme im Platform Supportcode verursacht.

Interessant!
Aber natürlich muss das Management-System irgendwie Zugriff auf die Hardware haben, es soll sie ja schliesslich überwachen. D.h. leichte Timing-Unterschiede auf diversen Bussen etc. werden leider nicht zu vermeiden sein. Ausser wenn man das Management-System abdreht - wenn es sich denn abdrehen lässt.

Genau das ist der Punk, man kann es nicht 100% abdrehen. Ohne das funktionieren heutige (x86) CPUs einfach nicht mehr.

Ich finde diese Management-System auch grundsätzlich ziemlich cool. Wenn man so richtig viele (physikalische) Server hat, ist man schon froh, wenn man einfach nur in einem Admin-Tool klicksi machen muss und damit z.B. einen Server der hängt "hart" rebooten kann. Oder ausschalten/einschalten/was auch immer man braucht. Blöd ist nur wenn sie sich eben nicht abdrehen lassen, und dann (wenn auch nur geringfügig) das System stören. Oder natürlich wenn sie Sicherheitslücken in z.B. ihrem Netzwerk-Stack haben.

Ja, in Servern bzw remote-managed Firmen-Workstations macht es wirklich Sinn, aber nicht in jeder normalen Desktop Hardware. Das ist ja einer der Gründe warum die freie Software unter Stallman entstanden ist. Damals gab es schon Bestreben in diese Richtung und Stallman hat regelrecht vorausgesehen wohin es in Zukunft (heute) führen wird.

hustbaer

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

kam raus, dass x86 CPUs in der Tat noch einen Ring -1 bis Ring -3 haben. Es war viele Jahre lang unbekannt. Dies ist nicht nur gruselig, es ist im höchsten Maße bedenklich. Man kann vor allem diese Accesslevel nicht in den Bitmasken in den global describer tables setzen und irgendwie nutzen. Falls du dich fragst wo das Verwendung findet. Die Virtualisierungshardware Vanderpool (Intel) und Pacifica (AMD) sind keine reine Hardwarelösung, sondern ein Hypervisor, der im Ring -1 läuft. Im Ring -2 läuft die Systemmanagementsoftware und Ring -3 ist nicht mal die eigentlich x86 CPU, sondern der eingebettete Kern (ARC oder 80586) der seine Geschichten macht.

Naja... die Grenzen sind da ein bisschen verschwommen denke ich. Also was ist eine "reine Hardwarelösung" und was nicht?

Schon CPUs wie der 6502 haben ein Instruction-ROM über das eine Instruction in mehrere Teile aufgesplittet wird. Ist das noch rein Hardware, weil's ein ROM ist? Spätere CPUs haben dann Microcode, was im Prinzip auch nix anderes ist bzw. nur eine konsequente fortführung des selbem Prinzips. Ist das noch rein Hardware? Was wenn man den Microcode updaten kann? Dann ist es kein ROM mehr? Immer noch rein Hardware? Und spätestens wenn man Virtualisierung in irgendeiner Form implementieren möchte, was schon bei einer MMU anfängt, werden die Dinge die zum Abarbeiten von einfachen Instruktionen oder auch nur Speicherzugriffen nötig sind ziemlich komplex. Da kann es schon Sinn machen das nicht mehr alles über klassischen Microcode zu machen sondern eine Abstraktionsebene darüber anzusetzen - nur halt mit Code der nicht vom OS kommt sondern quasi direkt in die CPU mit eingebaut ist. Bzw. aus dem UEFIA/BIOS kommt (AGESA & Co).

Und dass die Chip-Hersteller das nicht open-sourcen wollen ist denke ich auch klar, es würde ja viel darüber verraten wie diese Features in ihren CPUs umgesetzt sind.

Genau das ist der Punk, man kann es nicht 100% abdrehen. Ohne das funktionieren heutige (x86) CPUs einfach nicht mehr.

Bist du sicher was den 2. Punkt angeht? Ich hätte angenommen dass moderne x86 CPUs problemlos ohne dieses Management-OS im PCH/Chipset/... auskommen.

Finnegan

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

dann schau doch mal das tolle Spiel Oxygen not Included an. Lade einen 300+ Runden Spielestand etwa 50 mal. Wenn dann das Spiel noch unter 64 GB RAM frisst, haste Glück gehabt.

Lustig, das ist exakt eines der Spiele, wo mir der GC ebenfalls negativ aufgfallen ist. Es kommt nicht immer vor, aber bei manchen fortgeschrittenen Spielständen kommt es manchmal zu diesen regelmässigen Sekunden-Aussetzern alle paar Sekunden. Das ist extrem nervig. Das Ruckeln an sich ist nicht ganz so wild, sondern vor allem dass es oft dazu führt, dass man letztendlich wegen dem Aussetzer bei einer komplexen Maschine an eine falsche Stelle klickt und sich dabei schonmal gehörig was kaputt macht, wenn nach dem Fehlklick giftiges heißes Gas oder flüssige Lava in die Basis strömen ... es gibt da noch ein anderes Spiel namens "Eco" bei dem sich die UI-Programmierung hervorragend mit den GC-Aussetzern ergänzt: Das Spiel registriert zuerst (auch während einer GC-Pause) dass ein Mausklick stattgefunden hat, dann spielt eine kurze "Aktions-Animation" und erst wenn diese durchgelaufen ist, wird die eigentliche Position bestimmt, an die man geklickt hat. Da veklickt man sich ohnehin schon oft genug, aber wenn dazwischen auch noch so eine GC-Pause liegt, haut man sich regelmässig irgendwelche wichtigen Sachen kaputt... aber sind ja zum Glück nur Spiele - mag mir gar nicht ausmalen, wenn man sowas bei einem Programm hat, mit dem man tatsächlich Schaden anrichten kann. Stelle mir gerade eine Steuersoftware für einen Chirurgieroboter vor, bei der man sich regelmässig wegen dem GC "verklickt"

SeppJ

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

mag mir gar nicht ausmalen, wenn man sowas bei einem Programm hat, mit dem man tatsächlich Schaden anrichten kann. Stelle mir gerade eine Steuersoftware für einen Chirurgieroboter vor, bei der man sich regelmässig wegen dem GC "verklickt"

Was wir denken wie es ist: Die haben da eine professionelle Echtzeitumgebung, intensiv getestet, Hardware und Software optimal abgestimmt.
Wie es wirklich ist: Programm läuft unter Windows 95, macht einfach überhaupt keine Speicherfreigaben, und wird daher 1x die Stunde neu gestartet bevor der Speicher voll läuft

Finnegan

@SeppJ sagte in Mehrere Threads Anhalten/Weiterführen:

Wie es wirklich ist: Programm läuft unter Windows 95, macht einfach überhaupt keine Speicherfreigaben, und wird daher 1x die Stunde neu gestartet bevor der Speicher voll läuft

Noch eine Stufe darunter mit DOS wäre vielleicht gar nicht mal so verkehrt, wenn man nun wirklich nichts besseres zur Verfügung hat. Unter dem System haben Programme so viel Kontrolle, das ist fast wie direkt in das Programm als eigenes OS booten. Damit lassen sich Echtzeitanforderungen sicherlich recht gut erfüllen - wenn auch ziemlich fummelig, weil das OS halt generell nicht sonderlich viel kann

Was mir an DOS immer gut gefallen hat ist, dass man damit Dinge stricken kann, die sonst nur gehen, wenn man ein eigenes OS baut - ohne den Aufwand tatsächlich ein eigenes OS programmieren zu müssen.

Jockelx

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Ein weiterer Störfaktor unterhalb der OS- und oberhalb der Programmebene kann übrigens auch noch der Garbage Collector bei Java-VM oder .NET-Sprachen sein. Das habe ich schon bei einigen Spielen bewundern dürfen, die z.B. in einer .NET-Sprache geschreiben wuren (z.B. mit Unity Engine).

Ist etwas OT, aber permanent Objekte löschen oder erstellen sollte man in Spielen eh nicht. Die werden gepoolt (oder wie auch immer das deutsche Verb zu Object-pooling ist), also zu Beginn erstellt und dann ein/aus geblendet und das macht man auch z.B. in der Unreal-Engine (c++).

SeppJ

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

@SeppJ sagte in Mehrere Threads Anhalten/Weiterführen:

Wie es wirklich ist: Programm läuft unter Windows 95, macht einfach überhaupt keine Speicherfreigaben, und wird daher 1x die Stunde neu gestartet bevor der Speicher voll läuft

Noch eine Stufe darunter mit DOS wäre vielleicht gar nicht mal so verkehrt, wenn man nun wirklich nichts besseres zur Verfügung hat. Unter dem System haben Programme so viel Kontrolle, das ist fast wie direkt in das Programm als eigenes OS booten. Damit lassen sich Echtzeitanforderungen sicherlich recht gut erfüllen - wenn auch ziemlich fummelig, weil das OS halt generell nicht sonderlich viel kann

Ich wollte zuerst auch Win 3.1 schreiben, wegen kooperativem Multitaskings und weil's quasi DOS mit GUI ist, aber hab mir dann gedacht, dass wäre zu obskur
Außerdem hört man immer wieder echte Horrorgeschichten, wie etwa dass irgendwelche U-Boote mit alten Win 9x Computern laufen. Womöglich wegen genau solcher Anforderungen (Win 9x macht auch so gut wie nix im Hintergrund).

hustbaer

Ja, so altes DOS/Windows Zeug ist für soft-realtime oft nicht verkehrt. Am besten auf entsprechend alter Hardware.

Bei moderner Hardware kommen dann so Dinge zu Tragen wie @VLSI_Akiko angesprochen hat. Da werden dann gerne CPU oder Chipset Bugs maskiert indem die "CPU Firmware" das System so konfiguriert dass z.B. ein NMI ausgelöst wird wenn ein bestimmtes Register geschrieben wird, und da drin läuft dann Code der irgendeinen Workaround macht.

Soweit ich weiss sind sogar Sachen wie Rechnungen mit Denormals in modernen CPUs so implementiert dass irgend ein Interrupt ausgelöst wird wo das Ergebnis dann per Software ausgerechnet wird. Daher sollte man Denormals auch immer deaktivieren wenn man sie nicht braucht und die Berechnung zeitkritisch ist. Sonst kann es schnell passieren dass man z.B. tausende Nullen auf einen Akkumulatur draufaddiert der gerade einen Denormal-Wert hat. Und dadurch dann tausende Male den Overhead für die Software-Berechnung bezahlt.

Das kann einem dann auch unter DOS/... unerwartete Verzögerungen spendieren.

Finnegan

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Da werden dann gerne CPU oder Chipset Bugs maskiert indem die "CPU Firmware" das System so konfiguriert dass z.B. ein NMI ausgelöst wird wenn ein bestimmtes Register geschrieben wird, und da drin läuft dann Code der irgendeinen Workaround macht.

Ui, danke für die Info. Das war mir noch nicht bekannt. Ich habe bisher immer gedacht, dass bei CPU-Instruktionen auf Registern bestenfalls mehr oder weniger umfangreicher Mikrocode zur Ausführung kommt. Mit Ausnahme natürlich von General Protection Fault und Division durch 0 Handlern und sowas.

VLSI_Akiko

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Naja... die Grenzen sind da ein bisschen verschwommen denke ich. Also was ist eine "reine Hardwarelösung" und was nicht?

S390 oder zSeries Hardwarepartitionierung, aber Mainframes sind eine gaaaanz andere Geschichte. Aber grob kann man sagen, dass alles was unveränderlich in der CPU steck, ist Hardware. Dazu unten ein wenig mehr ...

Schon CPUs wie der 6502 haben ein Instruction-ROM über das eine Instruction in mehrere Teile aufgesplittet wird. Ist das noch rein Hardware, weil's ein ROM ist?

Ist Hardware, gibt Leute die Machen decapping von CPU/ROMs, fotografieren die Muster (Transistoren im Silizium) ab und übersetzen die Bitmasken mit einer Bildanalyse zurück in Code bzw Logikgatter. Ist quasi die Oberliga was reverse-engineering angeht. Kann man sich übrigends auch auf Youtube anschauen, bzw ist jedes Jahr beim CCC gefühlt ein Vortrag dabei, wo das gezeigt wird.

Spätere CPUs haben dann Microcode, was im Prinzip auch nix anderes ist bzw. nur eine konsequente fortführung des
selbem Prinzips. Ist das noch rein Hardware? Was wenn man den Microcode updaten kann? Dann ist es kein ROM mehr?

Microcode ist ein Lösung, die schon vor langer Zeit eingeführt wurde, um während der Produktion noch schnell Änderungen durchführen zu können. Eines der besten Beispiele für diese Weitsicht ist (ja, okay, ich mag das Teil ) der Motorola 68000 (1979). Das was dir als Microcode Update verkauft wird, updated nicht den Microcode in der CPU, sonst müsstest du ihn nicht in den BIOS integrieren oder wie bei Linux/BSD beim Booten als ucode laden.

Immer noch rein Hardware? Und spätestens wenn man Virtualisierung in irgendeiner Form implementieren möchte, was schon bei einer MMU anfängt, werden die Dinge die zum Abarbeiten von einfachen Instruktionen oder auch nur Speicherzugriffen nötig sind ziemlich komplex.

Ja und nein, eine MMU arbeitet eigentlich transparent zur CPU. Das wird ziemlich offensichtlich, wenn du ein System hast, wo CPU und MMU noch getrennte Bausteine sind. Ist es komplex? Oh ja, liegt aber größtenteils daran, dass es heutzutage so gut wie keine CPU mehr gibt, die kein Pipelining umsetzt.

Da kann es schon Sinn machen das nicht mehr alles über klassischen Microcode zu machen sondern eine Abstraktionsebene darüber anzusetzen - nur halt mit Code der nicht vom OS kommt sondern quasi direkt in die CPU mit eingebaut ist. Bzw. aus dem UEFIA/BIOS kommt (AGESA & Co).

Es gab da ja sehr nett klingende Versuche (die in der Praxis aber schiefgingen). Ein Beispiel hierfür wäre der VLIW Prozessor Transmeta. Was sich in der Richtung letztendlich durchgesetzt hat sind CLPDs und FPGAs.

Und dass die Chip-Hersteller das nicht open-sourcen wollen ist denke ich auch klar, es würde ja viel darüber verraten wie diese Features in ihren CPUs umgesetzt sind.

Wie die Features umgesetzt sind, kannst du in den Patenten nachlesen. Ich kann dir sagen warum da kaum jemand open-sourcen will. Einerseits sind es die Errata. Da sind nämlich ein paar Sachen dabei, die rechtliche Schritte ermöglichen würden. Und andererseits ein sehr beliebter Grund ist Intellectual Property (siehe Nvidia/3Dfx - manchmal ist es besser die "geklaute" Technologie zu kaufen, statt einen riesigen Prozess zu verlieren). Du kannst heute eigentlich keine neuen CPUs mehr designen ohne die Patente anderer zu verletzen. Ist genau wie bei der Entwicklung von Videocodecs, da wird alles mit Patenten "unterbunden/kontrolliert".

Genau das ist der Punk, man kann es nicht 100% abdrehen. Ohne das funktionieren heutige (x86) CPUs einfach nicht mehr.

Bist du sicher was den 2. Punkt angeht? Ich hätte angenommen dass moderne x86 CPUs problemlos ohne dieses Management-OS im PCH/Chipset/... auskommen.

Ja, bin ich, was x86 angeht. Der Platform Supportcode ist mehr als nur das Management-OS. Im Fall der Radeon Grafikkarten und deren ATOM BIOS ist es der darin verbaute ARM Prozessor. Hier liefert ein Teil des ATOM Bios die Trusted Firmware für den Trustzone Teil, ohne den die GPU nicht initialisiert. So ziemlich die gleichen ARM Cores stecken im PSP (Platform Support Processor) der Ryzen CPU's. Der ARM Core da drin ist für eine Authentifizierung zuständig. Der Ryzen tut nämlich bevor er mit dem Laden des BIOS/UEFI beginnt erstmal sicherstellen ob er selber legal ist und das Ganze darf. Alles Mechanismen um zu verhindern, dass da jemand etwas nachbaut oder einfach kopiert.

Achtung Geschichtsstunde: Deswegen konnten ja damals SIS/AMD/Cyrix/Rise die ganzen CPUs ja nachbauen und das stellenweise besser. Und Intel konnte nichts machen, weil man Nummern nicht markenrechtlich schützen kann. Deswegen der Name Pentium stat 80586. Und siehe da, die nächste 586 basierte CPU von AMD (k5) hatte Anfang echt Probleme mit dem Pentium mitzuhalten, weil sie nicht mehr ohne Konsequenten kopieren konnten. Die haben dann einfach das EV6 Protokoll von DEC (Alpha) lizensiert und damit die Athlons aufgebaut. Als sie dann noch etwa die Hälfte der Alpha Ingenieure übernommen hatten, hatten die plötzlichen einen Athlon, der ganz schön abging. Geschichtsstunde Ende. (Frag lieber nicht, mein ganzes Leben besteht nur aus Computerkram.)

Jendenfalls diese binären Blobs, die da in den kleinen SRAM vom ARM Core geladen werden (oder schlimmer, in die ROMS gebrannt sind*), sind das Problem. Die müssen da sein, oder die CPU beendet ihre Initialisierungphase nicht. Es gibt nur wenige CPUs, die so ein Blödsinn (es wird einem gerne als Secureboot und Co. verkauft) nicht machen, da wäre die chinesische MIPS CPU Loongson/Godson oder amüsanterweise auch die fetten POWER9 Prozessoren von IBM. (Deswegen gibt es die POWER9 Talos Workstation von Raptor Computing komplett ohne binäre Blobs.)

Es gibt einige Smartphones und Nintendo Geräte wo dieser ROM im ARM Bugs enthält, aufgrund dessen der Herstellen Securitylöcher nicht schließen kann und sich die "Raubkopierer" um diese Geäte auf Ebay kloppen.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Lustig, das ist exakt eines der Spiele, wo mir der GC ebenfalls negativ aufgfallen ist. Es kommt nicht immer vor, aber bei manchen fortgeschrittenen Spielständen kommt es manchmal zu diesen regelmässigen Sekunden-Aussetzern alle paar Sekunden. Das ist extrem nervig. Das Ruckeln an sich ist nicht ganz so wild, sondern vor allem dass es oft dazu führt, dass man letztendlich wegen dem Aussetzer bei einer komplexen Maschine an eine falsche Stelle klickt und sich dabei schonmal gehörig was kaputt macht, wenn nach dem Fehlklick giftiges heißes Gas oder flüssige Lava in die Basis strömen

Ja genau, nicht wahr? Das ist so nervtötend. Und wenn du dann noch jemand bist, der gerne diese Glühwürmchenrektoren baut, wo du zum Schluss 60+ Glühwürmchen in je einem Feld hast (und davon locker 10), da merkste dann so richtig warum man Spiele nicht in C# schreibt. Da kannst du 10 GHz haben und deine Framerate geht trotzdem unter 20 fps. Schau dir mal im Vergleich dazu Dwarf Fortress an. Das simuliert locker 100 mal mehr Aspekte in einer viel größeren Welt und läuft trotzdem deutlich besser.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Stelle mir gerade eine Steuersoftware für einen Chirurgieroboter vor, bei der man sich regelmässig wegen dem GC "verklickt"

Ich kenne es genau umgekehrt. In der Atomindustrie wurden die analog aufgebauten Schaltkreise im Containment vor ca 30+ Jahren durch Computer ersetzt. Vor 10 Jahren waren das noch PIC-MG Industriekarten, auf denen K6-3 verbaut waren (die haben die geringste Latenzabweichung bei Abarbeitung der immer selben Algorithmen - ein Problem von Caches und Superskalarität und out-of-order execution) auf denen nur Baremetal Programme liefen, die selten größer als 50 KB waren. Da wo es drauf ankommt, ist man sich der Probleme bewusst. Will damit sagen, ich denke nicht, dass so ein Chirogencomputer auch nur eine Etappe bei der Zulassung/Zertifizierung überleben würde. Naja, wie ich schon in einem meiner ersten Posts angedeutet habe, ich kann da stundenlang zu erzählen. Ich habe einfach überall da gearbeitet, wo es mal so richtig ans Eingemachte ging. Hint: Aktuell arbeite ich an Geräten, wo FPGAs als Coprozessoren verwendet werden um Timestamping und Timing in Nanosekundenbereich akurat und nachvollziehbar zu realisieren. Wir bauen auch unsere eigenen Bios, der komplett verriegelt wird und sich selbst prüft.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Was mir an DOS immer gut gefallen hat ist, dass man damit Dinge stricken kann, die sonst nur gehen, wenn man ein eigenes OS baut - ohne den Aufwand tatsächlich ein eigenes OS programmieren zu müssen.

Oh, da dürfte dir eventell Pure64 und BaremetalOS von ReturnInfinity eine Menge Spaß machen.

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Soweit ich weiss sind sogar Sachen wie Rechnungen mit Denormals in modernen CPUs so implementiert dass irgend ein Interrupt ausgelöst wird wo das Ergebnis dann per Software ausgerechnet wird. Daher sollte man Denormals auch immer deaktivieren wenn man sie nicht braucht und die Berechnung zeitkritisch ist.

Geht noch viel lustiger. Man nutzt einfach Traps/Interrupts um gewisse Aspekte in Software umzusetzen, statt in Hardware. Suche einfach mal nach 32 Bit ARM und 64Bit Divisionen, ich garantiere dir einen WTF?!?-Moment.

hustbaer

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Da werden dann gerne CPU oder Chipset Bugs maskiert indem die "CPU Firmware" das System so konfiguriert dass z.B. ein NMI ausgelöst wird wenn ein bestimmtes Register geschrieben wird, und da drin läuft dann Code der irgendeinen Workaround macht.

Ui, danke für die Info. Das war mir noch nicht bekannt. Ich habe bisher immer gedacht, dass bei CPU-Instruktionen auf Registern bestenfalls mehr oder weniger umfangreicher Mikrocode zur Ausführung kommt. Mit Ausnahme natürlich von General Protection Fault und Division durch 0 Handlern und sowas.

Upps, sorry, das war misverständlich. Ich meinte mit Register kein CPU Register sondern ein Register irgend eines Hardwarebausteins, z.b. im Chipset. Wie genau das Maskieren von CPU Bugs geht weiss ich nicht. Vermutlich gehört da zumindest ein Microcode-Update dazu.

hustbaer

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

Microcode ist ein Lösung, die schon vor langer Zeit eingeführt wurde, um während der Produktion noch schnell Änderungen durchführen zu können. Eines der besten Beispiele für diese Weitsicht ist (ja, okay, ich mag das Teil ) der Motorola 68000 (1979). Das was dir als Microcode Update verkauft wird, updated nicht den Microcode in der CPU, sonst müsstest du ihn nicht in den BIOS integrieren oder wie bei Linux/BSD beim Booten als ucode laden.

Ich dachte das liegt daran, dass die CPU einfach keinen nicht-flüchtigen Speicher dafür hat. Das liest man so auch öfter im Netz. Würde mich auf jeden Fall wundern wenn die mit Microcode Updates nicht auch wirklich am Microcode der CPU rumdoktorn. Wäre ja doch ziemlich hilfreich wenn das ginge. Und es würde mich wundern wenn es nicht gehen sollte.

Ja, bin ich, was x86 angeht. Der Platform Supportcode ist mehr als nur das Management-OS.

OK. Aber zumindest das Management-OS sollte man abdrehen können ohne dass die CPU Probleme bekommt.

Geht noch viel lustiger. Man nutzt einfach Traps/Interrupts um gewisse Aspekte in Software umzusetzen, statt in Hardware.

Rechnen mit Denormals ist doch genau sowas. Das betrifft ja ganz normale Maschinensprachbefehle, das ganze x87 Zeugs halt. x87 interessiert heute kaum mehr jemanden der wirklich Performance braucht, und daher gibt es auch keinen guten Grund für etwas wie Denormals viele Transistoren zu verbraten. Daher löst man es lieber so dass man der CPU "in Hardware" nur beibringt "Hilfe!" zu schreien, und irgend ein Trap/Interrupt Handler macht das dann "in Software".

Aber egal. Ist immer interessant weitere Beispiele zu hören/lesen.

Finnegan

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

Microcode ist ein Lösung, die schon vor langer Zeit eingeführt wurde, um während der Produktion noch schnell Änderungen durchführen zu können. Eines der besten Beispiele für diese Weitsicht ist (ja, okay, ich mag das Teil ) der Motorola 68000 (1979). Das was dir als Microcode Update verkauft wird, updated nicht den Microcode in der CPU, sonst müsstest du ihn nicht in den BIOS integrieren oder wie bei Linux/BSD beim Booten als ucode laden.

Echt? Ich hätte jetzt gedacht, dass Mikrocode in der CPU in einem flüchtigen Speicher liegt, in den bei der CPU-Initialisierung geaden wird. Dass dieser Code Teil des BIOS-ROMs ist oder sogar vom OS geladen wird hat mich daher bisher nicht verwundert. oder hab ich das was missverstanden?

Du kannst heute eigentlich keine neuen CPUs mehr designen ohne die Patente anderer zu verletzen. Ist genau wie bei der Entwicklung von Videocodecs, da wird alles mit Patenten "unterbunden/kontrolliert".

Ziemliche Innovationsbremse IMHO. Vor allem wenn man als kleiner Entwickler mit frischen Verbesserungsideen neu in so einen Markt einsteigen will. Es gibt sicherlich einige Erfindungen, bei denen es so hohe Entwicklungskosten gab, dass sich der Schutz rechtfertigen lässt. Leider gibt es aber auch viel zu viele "Patente" auf die man intuitiv und unabhängig selbst kam, nachem man eine halbe Stude über ein Problem nachgedacht hat. Nur um dann festzustellen, dass es schon jemand patentiert hat

Der Ryzen tut nämlich bevor er mit dem Laden des BIOS/UEFI beginnt erstmal sicherstellen ob er selber legal ist und das Ganze darf. Alles Mechanismen um zu verhindern, dass da jemand etwas nachbaut oder einfach kopiert.

Doofe Frage: Werden Chips tatsächlich kopiert wie das ein desinteressierter Informatik-Erstemester tun würde? Copy+Paste ohne zu verstehen, was da passiert? Wäre es nicht ein leichtes, den Verifikationsmechanismus entweder wegzulassen oder so zu modifizieren, dass er auch meine Kopie akzeptiert?

...

Achtung Geschichtsstunde: Deswegen konnten ja damals SIS/AMD/Cyrix/Rise die ganzen CPUs ja nachbauen und das stellenweise besser.

... die Antwort ist vermutlich "Nein"

Schau dir mal im Vergleich dazu Dwarf Fortress an. Das simuliert locker 100 mal mehr Aspekte in einer viel größeren Welt und läuft trotzdem deutlich besser.

Factorio ist auch ein Beispiel, das bezüglich exzellenter Performance bei riesigen Welten mit komplexen Maschinen besonders hervorsticht. Interessant ist bei Factorio auch der Netzwerkcode - das Spiel verursacht im Multiplayer nur minimalsten Traffic. Da fährt jeder Client seine eigene, reproduzierbare Simulation und lediglich die User-Eingaben werden übers Netzwerk synchronisiert. Wenn zwei Computer das gleiche berechnen, sollten sie schliesslich auch zum gleichen Ergebnis kommen*, da muss man nicht jeden Zwischenschritt übers Netzwerk übertragen.

(* Bei Fliesskommaoperationen kann das allerdings schonmal etwas haarig werden. Besonders wenn die Clients auch noch unterschiedliche CPU-Architekturen fahren)

Hint: Aktuell arbeite ich an Geräten, wo FPGAs als Coprozessoren verwendet werden um Timestamping und Timing in Nanosekundenbereich akurat und nachvollziehbar zu realisieren.

Das klingt schon recht anspruchsvoll. Mir würden ja schon zuverlässige 16ms reichen, damit bei 60fps der nächste Frame rechtzeitig fertig wird

Oh, da dürfte dir eventell Pure64 und BaremetalOS von ReturnInfinity eine Menge Spaß machen.

Ich hatte schon den Verdacht, dass es da sowas geben muss. Nicht immer braucht oder will man den Overhead, den ein ausgewachsenes OS mitbringt. Von BaremetalOS habe ich auf jeden Fall schonmal gehört. Schau ich mir vielleicht mal an für ein paar Hobby-Spielereien

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Upps, sorry, das war misverständlich. Ich meinte mit Register kein CPU Register sondern ein Register irgend eines Hardwarebausteins, z.b. im Chipset. Wie genau das Maskieren von CPU Bugs geht weiss ich nicht. Vermutlich gehört da zumindest ein Microcode-Update dazu.

Ah verstehe. Mache nicht viel mit Hardware, aber diese "Register" sind mir schon ein Begriff.

VLSI_Akiko

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Ich dachte das liegt daran, dass die CPU einfach keinen nicht-flüchtigen Speicher dafür hat. Das liest man so auch öfter im Netz. Würde mich auf jeden Fall wundern wenn die mit Microcode Updates nicht auch wirklich am Microcode der CPU rumdoktorn. Wäre ja doch ziemlich hilfreich wenn das ginge. Und es würde mich wundern wenn es nicht gehen sollte.

Da ist mir nichts bekannt, dass es da eine Art Flash oder so für x86 CPU's gibt. Wäre ja auch fatal, wenn man sowas direkt in die CPU "brennen" könnte, denk da nur mal Malware, uiuiui... Es gibt allerdings ein paar ARMs die sowas haben.

OK. Aber zumindest das Management-OS sollte man abdrehen können ohne dass die CPU Probleme bekommt.

Ja, da gibt es dank dieser reverse-engineering Geschichten mitlerweile Tools, die diese Sachen aus BIOS Update Images und wohl auch aus dem BIOS-Flash direkt "rauschneiden" können. Oder du nutzt Coreboot/Libreboot. Ich habe Libreboot auf einem ASUS KGPE-16D (dual Sockel G34 - Opterons) laufen, musste dafür meine eigenen SPI Flash zurechtfriemeln. Alles andere als spaßig und was noch viel schlimmer ist. Es ist alles autoconfig, es gibt kein Bios-Menu, nichts was du einstellen kannst. Und die Stabilität ist, naja, bescheiden, von 128GB DDR3 reg ECC werden zum Beispiel nur 64 erkannt und so weiter.

Rechnen mit Denormals ist doch genau sowas. Das betrifft ja ganz normale Maschinensprachbefehle, das ganze x87 Zeugs halt. x87 interessiert heute kaum mehr jemanden der wirklich Performance braucht, und daher gibt es auch keinen guten Grund für etwas wie Denormals viele Transistoren zu verbraten. Daher löst man es lieber so dass man der CPU "in Hardware" nur beibringt "Hilfe!" zu schreien, und irgend ein Trap/Interrupt Handler macht das dann "in Software".

Ich glaube hier gibts ein kleines Missverständnis. Ich meine die div und udiv Opcode, also Integer Divisionen. 64 Bit Integerdivisionen gehen auf nahezu jeder 32 Bit CPU in Hardware, außer eben vielen 32 Bit ARMS ... und ja, das gilt auch für die Cortex-A Reihe. Das Ganze sieht dann so aus, wenn es mal wieder jemand in seinem Treibern vermasselt hat, und ich darfs fixen:

| ERROR: modpost: "__aeabi_ldivmod" [drivers/spi/spi-cadence-quadspi.ko] undefined!
| ERROR: modpost: "__aeabi_uldivmod" [drivers/spi/spi-cadence-quadspi.ko] undefined!

Weil es ein Linkproblem ist, bekommste nicht mal die Information wo es passiert. Nun darf ich jede Division in dem Treiber checken und dann durch die Kernelimplementierung ersetzen.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Echt? Ich hätte jetzt gedacht, dass Mikrocode in der CPU in einem flüchtigen Speicher liegt, in den bei der CPU-Initialisierung geaden wird. Dass dieser Code Teil des BIOS-ROMs ist oder sogar vom OS geladen wird hat mich daher bisher nicht verwundert. oder hab ich das was missverstanden?

Nein, es gibt einen "festeingebrannten" Microcode der hoffentlich bugfrei ist und während der Laufzeit geupdated werden kann, indem einfach "Pointer" auf den neuen Code umgelenkt werden. Es kann gut sein, dass die CPU einen kleinen versteckten SRAM Bereich hat (oder eben einer der Caches), wo der Microcode reingeladen wird. Sowas über den normalen RAM zu machen ist ein bisschen bescheuert, weils einfach zu langsam wäre. Kannst es dir ein wenig wie BIOS shadowing vorstellen, nur dass nicht in den RAM sondern in so einen kleines SRAM/Cache geshadowed wird. Sind die Bugs im Microcode zu krass, gibts ein neues Stepping der CPU. Oft werden auf diese Weise auch Sachen verborgen, die noch in der CPU sind. Kannst du dich noch an 3DNOW/3DNOW! aus den K6 CPUs und frühen Athlons erinnern, oder an das FMA4 aus den Bulldozer/Piledriver/Excavator CPUs? Alle Ryzen CPUs können das ohne Probleme, da ist es nur per Microcode aus der CPU-Flags Liste rausgenommen worden.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Ziemliche Innovationsbremse IMHO. Vor allem wenn man als kleiner Entwickler mit frischen Verbesserungsideen neu in so einen Markt einsteigen will. Es gibt sicherlich einige Erfindungen, bei denen es so hohe Entwicklungskosten gab, dass sich der Schutz rechtfertigen lässt. Leider gibt es aber auch viel zu viele "Patente" auf die man intuitiv und unabhängig selbst kam, nachem man eine halbe Stude über ein Problem nachgedacht hat. Nur um dann festzustellen, dass es schon jemand patentiert hat

Ursprünglich war das Patentsystem dafür gedacht, dass du zumindest deine Entwicklungskosten wieder reinholen kannst. Es war zeitlich stark begrenzt (5-10 Jahre? keine Ahnung). Aber irgendwann wurde das komplett pervertiert und es gibt da einige Player, die da stark dazu beitragen (* hust * Nvidia, Oracle).

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

(* Bei Fliesskommaoperationen kann das allerdings schonmal etwas haarig werden. Besonders wenn die Clients auch noch unterschiedliche CPU-Architekturen fahren)

Das sollte eigentlich nicht vorkommen, dafür gibt es ja eben die IEEE754 Spec an die sich alle aktuellen CPU's halten. Ich kann mir vorstellen, dass sowas nur passiert wenn du auf der einen Architektur alles/einiges in floats machst und auf anderen in doubles.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Das klingt schon recht anspruchsvoll. Mir würden ja schon zuverlässige 16ms reichen, damit bei 60fps der nächste Frame rechtzeitig fertig wird

Naja, hier gehts halt darum ob du nen Knöllchen für 15 km/h oder 200 km/h zu schnell bekommst. * duck * Es geht im Prinzip um Existenzen (Führerscheinverlust) und da werden keine halbe Sachen gemacht. Ein anderes Szenario ist das Erkennen von 500 Nummernschildern pro Minute aus 50 Megapixel Bildern mit einer Erfolgsrate von 95%+ auf 3-4 Spuren mit bis zu 8 Kameras. Gibts da irgendwo auch nur 50 Mikrosekunden Verzögerung, sind die ganzen Messvorgänge für die Katz. (Ist auch ohne DSPs oder FPGAs nicht mehr machbar.)

hustbaer

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

Da ist mir nichts bekannt, dass es da eine Art Flash oder so für x86 CPU's gibt. Wäre ja auch fatal, wenn man sowas direkt in die CPU "brennen" könnte, denk da nur mal Malware, uiuiui... Es gibt allerdings ein paar ARMs die sowas haben.

Ja, eben. Und genau weil x86 CPUs kein solches Flash haben, muss man die Microcode Updates bei jedem Boot neu über's BIOS/UEFI einspielen. Dass es im BIOS/UEFI steht ist also kein Argument dafür dass die Microcode Updates "nicht wirklich Microcode in der CPU updaten".

Ich glaube hier gibts ein kleines Missverständnis. Ich meine die div und udiv Opcode, also Integer Divisionen. 64 Bit Integerdivisionen gehen auf nahezu jeder 32 Bit CPU in Hardware, außer eben vielen 32 Bit ARMS ... und ja, das gilt auch für die Cortex-A Reihe. Das Ganze sieht dann so aus, wenn es mal wieder jemand in seinem Treibern vermasselt hat, und ich darfs fixen:

Ich hatte schon verstanden dass du Integerdivisionen meinst. Ich meine nur: ob jetzt wie bei ARM die Integerdivisionen fehlt, oder wie bei x86 nur die Fähigkeit mit Denormals zu rechnen - beides sind für mich Beispiele von fehlenden Features.

Ursprünglich war das Patentsystem dafür gedacht, dass du zumindest deine Entwicklungskosten wieder reinholen kannst. Es war zeitlich stark begrenzt (5-10 Jahre? keine Ahnung)

Patente in D und AT sind aktuell für max. 20 Jahre gültig. Lange, aber immer noch sehr vernünftig verglichen mit z.B. dem amerikanischen Copyright, welches aktuell für 70 Jahre nach dem Tod des Verfassers gilt.

Das sollte eigentlich nicht vorkommen, dafür gibt es ja eben die IEEE754 Spec an die sich alle aktuellen CPU's halten.

Soweit ich weiss sind die ganzen SIMD Geschichten in aktuellen CPUs nicht IEEE-konform. Eben weil bei Sachen wie Denormals die Kosten/Nutzen Rechnung nicht passt. Bei x86 gibt's immer noch die ganzen x87 Instruktionen wenn man IEEE braucht. Bei anderen Architekturen: keine Ahnung.

VLSI_Akiko

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Soweit ich weiss sind die ganzen SIMD Geschichten in aktuellen CPUs nicht IEEE-konform. Eben weil bei Sachen wie Denormals die Kosten/Nutzen Rechnung nicht passt. Bei x86 gibt's immer noch die ganzen x87 Instruktionen wenn man IEEE braucht. Bei anderen Architekturen: keine Ahnung.

Ahh, wie reden von SIMD Units und nicht von den FPUs. Ja, dass ist eine andere Geschichte aber auch die lassen sich konfigurieren. Da gibt es richtig Opcodes für um die richtig einzustellen. Wobei, ARMs NEON ist 100% ieee754 konform und das gilt wohl auch für SSE/AVX. Oh schau an, Agner Fog hat dazu auch was zu sagen. Das Problem ist wohl die OoO execution innerhalb der SIMD Units. Man lernt eben nie aus.