Ich meinte oben, dass RDRAND/RDSEED unter i386 (als Befehlssatz des 80386) nicht existiert. Zugegebenermaßen blöd formuliert, aber durch den Kontext (siehe mindestens den Satz davor) sollte sie zumindest angezweifelt werden. In dieser Hinsicht stimme ich Ihnen zu.
Daher bitte ich darum, meine fälschliche Formulierung zu entschuldigen.
2.
[...], keine Rede von i386 [...]
Die Rede war von (siehe auch meine Zitierung oben):
Die Industrie soll gefälligst gescheite Standards festlegen, und die dann einfach implementieren. Und die Gegenseite implementiert auch einfach diesen Standard. Und fertig ist die Laube!
Das funktioniert oftmals nur im Reich der Fantasie, denn dafür müssten die Standards ab einem gewissen Zeitpunkt eindeutig formuliert sein und keine Änderungen oder Erweiterungen erhalten. Ist dies nicht der Fall, wird es sehr schnell sehr schwierig, den Standard aus der Perspektive aller Nutzer objektiv korrekt umzusetzen.
Es ist ein nicht lösbares Problem, außer der Standard ist strikt versioniert und abwärtskompatibel, was effektiv einem Standardprozess, der laufend neue Standards oder strikte Erweiterungen ausarbeitet und veröffentlicht, gleichkommt.
Dafür müssten die beteiligten Parteien sich maximal kooperativ verhalten. Das tun sie aber nicht, oder nur in einem gewissen Maße, da sie direkte Konkurrenten sind. Außerdem müsste aber jede Umsetzung/Implementierung regelmäßig erneuert, überarbeitet oder ergänzt werden. Das ist bei modernen Mikroprozessoren nicht ganz trivial, da es sich um integrierte Schaltkreise oder SoCs handelt. Höchstens FPGAs bieten hier beschränkte Möglichkeiten, aber die sind in der Regel sehr viel aufwändiger zu programmieren/testen und teuerer oder langsamer.
Die Vorschläge/Wünsche des OP sind quasi nicht umsetzbar, jedenfalls nicht in einer grundlegend unveränderten Situation.
Seit Ivy Bridge sind RDRAND/RDSEED Teil von Intel64, IA-32 und seit 2015 auch Teil von AMD64. Die ISA-Bezeichnung IA-32 wird auch als Retronym für i386 genutzt, eine geläufige Bezeichnung für Intels ersten 32Bit-Befehlssatz, der mit dem 80386 eingeführt und seitdem kontinuierlich erweitert wurde.
Damit war also indirekt auch von i386 (als IA-32) die Rede, denn dieser wurde um RDRAND/RDSEED ergänzt, denn der ursprüngliche (alte) i386-Befehlssatz des 80386 ist ein Beispiel für eine Version des x86 mit 32Bit (bzw. Intels Implementierung dessen), die diese Befehle nicht enthält.
Fakt ist, dass RDRAND/RDSEED Teil einer Entwicklung von Standards bzw. deren Implementierungen sind, die bis zum i386 zurückreichen. Daher war/ist i386 auch Teil dieser Diskussion - zumindest exemplarisch für einen Prozessor bzw. eine Befehlssatzversion, der bzw. die diese Befehle nicht unterstützt.
3.
[...] oder gar früher [als i386]
Davon hatte nun wirklich niemand gesprochen. Versuchen Sie hier, mir etwas in den Mund zu legen, was ich gar nicht geäußert hatte?
Von Verfluchtnochmal_5987109 am Fr, 19. Juli 2019 um 19:28 #
Du hast wortwörtlich in einem eigenständigen Satz geschrieben "RDAND/RDSEED existieren nicht erst seit dem i386" und daran gibts nichts zu deuten, du scheinst dich herausred3n zu wollen und erinnerst an einen Kasper im heise forum der in unzähligen threads behauptet AMD könnte das gar nicht fixen weil sie dann inkompatibel zu Intel werden würden weil 20 Jahre alt und hast du nicht gesehen
Abgesehen davon haben die beiden Instruktionen einen Scheissdreck miteinander zu tun, weder in der technischen Funktionsweise noch beim Einführungszeitpunkt
Du hast wortwörtlich in einem eigenständigen Satz geschrieben "RDAND/RDSEED existieren nicht erst seit dem i386" und daran gibts nichts zu deuten, [...]
Ja, es hatte sich irgendwie ein "erst" eingeschummelt, denn ich meinte eigentlich "RDAND/RDSEED existieren nicht erst seit dem i386". Die Aussage bleibt dann immernoch mehrdeutig. Das hatte ich doch schon zugegeben und mich dafür entschuldigt (siehe oben). Fehler passieren.
[...] du scheinst dich herausred3n zu wollen und erinnerst an einen Kasper im heise forum der in unzähligen threads behauptet AMD könnte das gar nicht fixen weil sie dann inkompatibel zu Intel werden würden weil 20 Jahre alt und hast du nicht gesehen
Also belassen Sie es doch bitte bei diesem Schein, solange Sie keine stichhaltigen Beweise für Ihre Anklage ohne Sachbezug haben, und befassen sich lieber mit dem Inhalt des Kommentars.
Leider kann ich Ihnen nicht unabstreitbar beweisen, dass ich bisher kein Heise-Profil erstellt habe, sonst würde ich es tun. Das müssen Sie mir wohl glauben.
Andererseits haben Sie auch keine Beweise dafür, dass ich ein solches Profil besäße. Der Kläger trägt die Beweislast und im Zweifelsfall wird immer zugunsten des Angeklagten entschieden. Also lassen wir es lieber ganz sein, oder?
Abgesehen davon haben die beiden Instruktionen einen Scheissdreck miteinander zu tun, weder in der technischen Funktionsweise noch beim Einführungszeitpunkt
Letzteres gibt es nämlich erst seit broadwell
Einführungszeitpunkt geschenkt... aber was hat das eigentlich mit der Kernaussage meiner Kommentare zu tun? Sie ist weiterhin unangetastet schlüssig.
Von Verfluchtnochmal_5987109 am Fr, 19. Juli 2019 um 21:25 #
In der deutschen Sprache bedeutet "existiert nicht erst seit" sinngemäß "existiert schon länger als"
Sie haben deswegen einen Scheissdreck miteinander zu tun weil RDAND ein explizit in Hardware implementer Generator ist während RDSEED ähnlich software Implementierungen auf "Grundrauschen des Systems" basiert
Da liegen Welten dazwischen, RDAND sollte kryptografischen Ansprüchen genügen während RDSEED dazu gedacht ist einen prng zu seeden
Was ein prng, seed unddder Unterschied zwischen einem prng und einer "echten" random Quelle sind darfst du Google fragen und nur dann undnnachdem du die basics verstanden hast kommst du zurück undkkommentierst solche Themen
Als Grundvoraussetzung lernst du mal vorher die deutsche Sprache, siehe ersten Satz
1.
Ich meinte oben, dass RDRAND/RDSEED unter i386 (als Befehlssatz des 80386) nicht existiert. Zugegebenermaßen blöd formuliert, aber durch den Kontext (siehe mindestens den Satz davor) sollte sie zumindest angezweifelt werden.In dieser Hinsicht stimme ich Ihnen zu.
Daher bitte ich darum, meine fälschliche Formulierung zu entschuldigen.
2.
Die Rede war von (siehe auch meine Zitierung oben):Das funktioniert oftmals nur im Reich der Fantasie, denn dafür müssten die Standards ab einem gewissen Zeitpunkt eindeutig formuliert sein und keine Änderungen oder Erweiterungen erhalten. Ist dies nicht der Fall, wird es sehr schnell sehr schwierig, den Standard aus der Perspektive aller Nutzer objektiv korrekt umzusetzen.Es ist ein nicht lösbares Problem, außer der Standard ist strikt versioniert und abwärtskompatibel, was effektiv einem Standardprozess, der laufend neue Standards oder strikte Erweiterungen ausarbeitet und veröffentlicht, gleichkommt.
Dafür müssten die beteiligten Parteien sich maximal kooperativ verhalten. Das tun sie aber nicht, oder nur in einem gewissen Maße, da sie direkte Konkurrenten sind.
Außerdem müsste aber jede Umsetzung/Implementierung regelmäßig erneuert, überarbeitet oder ergänzt werden. Das ist bei modernen Mikroprozessoren nicht ganz trivial, da es sich um integrierte Schaltkreise oder SoCs handelt. Höchstens FPGAs bieten hier beschränkte Möglichkeiten, aber die sind in der Regel sehr viel aufwändiger zu programmieren/testen und teuerer oder langsamer.
Man beachte auch die unterschiedlichen Bezeichnungen für die Implementierungen (Umsetzungen) der Befehlssätze. Sie unterscheiden/unterschieden sich in Details auch abseits von unabsichtlichen Fehlern. Das hat vermutlich größtenteils historische, technische oder patentrechtliche Ursachen statt absichtlicher Inkompatibilitätsinteressen.
Die Vorschläge/Wünsche des OP sind quasi nicht umsetzbar, jedenfalls nicht in einer grundlegend unveränderten Situation.
Seit Ivy Bridge sind RDRAND/RDSEED Teil von Intel64, IA-32 und seit 2015 auch Teil von AMD64. Die ISA-Bezeichnung IA-32 wird auch als Retronym für i386 genutzt, eine geläufige Bezeichnung für Intels ersten 32Bit-Befehlssatz, der mit dem 80386 eingeführt und seitdem kontinuierlich erweitert wurde.
Damit war also indirekt auch von i386 (als IA-32) die Rede, denn dieser wurde um RDRAND/RDSEED ergänzt, denn der ursprüngliche (alte) i386-Befehlssatz des 80386 ist ein Beispiel für eine Version des x86 mit 32Bit (bzw. Intels Implementierung dessen), die diese Befehle nicht enthält.
Fakt ist, dass RDRAND/RDSEED Teil einer Entwicklung von Standards bzw. deren Implementierungen sind, die bis zum i386 zurückreichen.
Daher war/ist i386 auch Teil dieser Diskussion - zumindest exemplarisch für einen Prozessor bzw. eine Befehlssatzversion, der bzw. die diese Befehle nicht unterstützt.
3.
Davon hatte nun wirklich niemand gesprochen. Versuchen Sie hier, mir etwas in den Mund zu legen, was ich gar nicht geäußert hatte?Du hast wortwörtlich in einem eigenständigen Satz geschrieben "RDAND/RDSEED existieren nicht erst seit dem i386" und daran gibts nichts zu deuten, du scheinst dich herausred3n zu wollen und erinnerst an einen Kasper im heise forum der in unzähligen threads behauptet AMD könnte das gar nicht fixen weil sie dann inkompatibel zu Intel werden würden weil 20 Jahre alt und hast du nicht gesehen
Abgesehen davon haben die beiden Instruktionen einen Scheissdreck miteinander zu tun, weder in der technischen Funktionsweise noch beim Einführungszeitpunkt
Letzteres gibt es nämlich erst seit broadwell
erstseit dem i386". Die Aussage bleibt dann immernoch mehrdeutig. Das hatte ich doch schon zugegeben und mich dafür entschuldigt (siehe oben). Fehler passieren.Also belassen Sie es doch bitte bei diesem Schein, solange Sie keine stichhaltigen Beweise für Ihre Anklage ohne Sachbezug haben, und befassen sich lieber mit dem Inhalt des Kommentars.Leider kann ich Ihnen nicht unabstreitbar beweisen, dass ich bisher kein Heise-Profil erstellt habe, sonst würde ich es tun. Das müssen Sie mir wohl glauben.
Andererseits haben Sie auch keine Beweise dafür, dass ich ein solches Profil besäße. Der Kläger trägt die Beweislast und im Zweifelsfall wird immer zugunsten des Angeklagten entschieden.
Einführungszeitpunkt geschenkt... aber was hat das eigentlich mit der Kernaussage meiner Kommentare zu tun? Sie ist weiterhin unangetastet schlüssig.Also lassen wir es lieber ganz sein, oder?
Außerdem: Wenn "die beiden Instruktionen einen Scheissdreck miteinander zu tun" hätten, was mag dann "
RDSEEDis similar toRDRANDand provides higher level access to the entropy hardware." oder das bedeuten?In der deutschen Sprache bedeutet "existiert nicht erst seit" sinngemäß "existiert schon länger als"
Sie haben deswegen einen Scheissdreck miteinander zu tun weil RDAND ein explizit in Hardware implementer Generator ist während RDSEED ähnlich software Implementierungen auf "Grundrauschen des Systems" basiert
Da liegen Welten dazwischen, RDAND sollte kryptografischen Ansprüchen genügen während RDSEED dazu gedacht ist einen prng zu seeden
Was ein prng, seed unddder Unterschied zwischen einem prng und einer "echten" random Quelle sind darfst du Google fragen und nur dann undnnachdem du die basics verstanden hast kommst du zurück undkkommentierst solche Themen
Als Grundvoraussetzung lernst du mal vorher die deutsche Sprache, siehe ersten Satz