Warum nicht gleich für RISC programmieren?
Warum nicht gleich für RISC programmieren?
In modernen Prozessoren werkeln schon seit Generationen intern RISC Prozessoren die x86/x86_64 Befehle über einen kleinen Kompatibiltätslayer auf der CPU-Die Fläche ab.
Warum umgeht man nun diesen scheinbar unnötigen Schritt über den x86-layer nicht einfach?
Man könnte doch die x86-calls temporär umleiten, also eine Art Kompatibilitätslayer im Kernel, der diese calls in RISC übersetzt. Auf diese Weise hätten die Coder länger Zeit, Ihre Programme nach und nach an die neue Architektur anzupassen. Dann könnten die Kernel-maintainer dann Schritt für Schritt die x86-calls reduzieren, bis sie ganz aus dem Kernel verschwunden sind.
Ein weiterer Vorteil: Noch weitere Verbreitung/Verwendbarkeit ein und des selben codes auf vielen Plattformen.
Außerdem könnten auf diese Weise - Quellcodebereinigungen in allen FOSS Projekten vorausgesetzt - diverse Sicherheitslücken von Grund auf angegangen werden.
Was meint Ihr?
Warum umgeht man nun diesen scheinbar unnötigen Schritt über den x86-layer nicht einfach?
Man könnte doch die x86-calls temporär umleiten, also eine Art Kompatibilitätslayer im Kernel, der diese calls in RISC übersetzt. Auf diese Weise hätten die Coder länger Zeit, Ihre Programme nach und nach an die neue Architektur anzupassen. Dann könnten die Kernel-maintainer dann Schritt für Schritt die x86-calls reduzieren, bis sie ganz aus dem Kernel verschwunden sind.
Ein weiterer Vorteil: Noch weitere Verbreitung/Verwendbarkeit ein und des selben codes auf vielen Plattformen.
Außerdem könnten auf diese Weise - Quellcodebereinigungen in allen FOSS Projekten vorausgesetzt - diverse Sicherheitslücken von Grund auf angegangen werden.
Was meint Ihr?
Wir erleben gerade die letzte Ruhe vor dem Sturm. Genießen wir sie, solange es noch geht
Re: Warum nicht gleich für RISC programmieren?
Ich meine: ich hätte gerne ’ne Informationsquelle. Obwohl ich von CPU-Design so gar keine Ahnung habe, würde ich die Aussage „In modernen Prozessoren werkeln schon seit Generationen intern RISC Prozessoren die x86/x86_64 Befehle über einen kleinen Kompatibiltätslayer auf der CPU-Die Fläche ab.“ in der Form erstmal stark anzweifeln. Insbesondere auch die Annahme, dass es, sofern denn vorhanden, direkt nutzbar wäre.
Wenn du mal eine ARM-Maschine mit etwa qemu als „Kompatibilitätslayer“ auf einem x86-System emuliert hast, könntest du dir vorstellen, dass das möglicherweise nicht die beste Idee ist, und aufgrund der geringen Performance kaum Akzeptanz finden dürfte.c1ue hat geschrieben:08.12.2018 02:34:09Man könnte doch die x86-calls temporär umleiten, also eine Art Kompatibilitätslayer im Kernel, der diese calls in RISC übersetzt.
Re: Warum nicht gleich für RISC programmieren?
Soweit ich mich an Inhalte aus meinem Studium sind x86-Prozessoren maximal RISC ähnlich.
Was deine Frage angeht, natürlich kannst du dich bei x86 Prozessoren auch auf den reduzierten Befehlssatz beschränken, allerdings gewinnst du damit nichts, du verlierst eher Performance. Als Beispiel, warum sollte ich AES in Software machen, wenn die CPU doch dafür beschleunigte Befehle bietet?
Was deine Frage angeht, natürlich kannst du dich bei x86 Prozessoren auch auf den reduzierten Befehlssatz beschränken, allerdings gewinnst du damit nichts, du verlierst eher Performance. Als Beispiel, warum sollte ich AES in Software machen, wenn die CPU doch dafür beschleunigte Befehle bietet?
Re: Warum nicht gleich für RISC programmieren?
Ich hab mal diese Seite (in Englisch) ausgegraben:
https://stackoverflow.com/questions/580 ... processors
Da ich diese Behauptung nun öfter gelesen haben, dass intern RISC werkelt, ging ich davon aus, dass dies auch zutreffend wäre.
https://stackoverflow.com/questions/580 ... processors
Da ich diese Behauptung nun öfter gelesen haben, dass intern RISC werkelt, ging ich davon aus, dass dies auch zutreffend wäre.
Wir erleben gerade die letzte Ruhe vor dem Sturm. Genießen wir sie, solange es noch geht
Re: Warum nicht gleich für RISC programmieren?
Einerseits steht da „RISC like“, andererseits steht genau in dem Thread auch gleich der Grund, warum nicht direkt drauf zugegriffen wird, sondern über den Standard-x86-Befehlssatz: die interne Verarbeitung kann von Modell zu Modell verschieden sein, und man müsste seinen Kram für jedes einzelne CPU-Modell neu kompilieren. Dazu müssten die Compilerbauer ihre Sachen für jedes einzelne Modell anpassen, die ganzen Libs müssten für jedes einzelne Modell angepasst werden, etc..
Re: Warum nicht gleich für RISC programmieren?
c1ue hat geschrieben:08.12.2018 02:34:09Man könnte doch die x86-calls temporär umleiten, also eine Art Kompatibilitätslayer im Kernel, der diese calls in RISC übersetzt.
Sowas willst Du nicht. Wirklich nicht. Eine zusätzliche Abstraktionsschicht würde hier nur unnötige Kosten verursachen. Kosten im Sinne von "sehr langsam machen". Grade im Kernel will man keine zusätzlichen Umwege.
Du willst vorschlagen, dass jetzt alle FOSS Projekte in RISC Microcode geschrieben werden? Nen ähnlich Stand gabs vor ~50 Jahren mal, und dann hat man Hochsprachen wie Fortran und C entwickelt.c1ue hat geschrieben:08.12.2018 02:34:09Außerdem könnten auf diese Weise - Quellcodebereinigungen in allen FOSS Projekten vorausgesetzt - diverse Sicherheitslücken von Grund auf angegangen werden.
Als Programmierer willst Du, dass es Dir weitgehend egal sein kann, welche Architektur darunter werkelt. Das soll gefälligst das Problem der Compilerbauer sein - das Hobby (zugegebenermaßen ein sehr interessantes) bzw den Beruf haben die sich schließlich selbst ausgesucht
Und warum glaubst Du, dass Sicherheitslücken durch die Verwendung von RISC Instruktionen seltener auftreten? Oder hab ich Dich falsch verstanden?
Re: Warum nicht gleich für RISC programmieren?
So etwas gab es im Prinzip sogar schon einmal. Die CPUs von Transmeta hatten eine völlig eigenständige Architektur (zwar nicht RISC sondern VLIW ), die mittels Software die x86-Instruktionen in Befehle für die CPU umgesetzt hat. Der Umsetzer lief allerdings nicht im Kernel, sondern eine Schicht darunter. Heute würde man die x86-Schicht wohl als virtuelle Maschine bezeichnen. In Sachen Geschwindigkeit waren sie aber stets der Intel- und AMD-Konkurrenz unterlegen.eggy hat geschrieben:09.12.2018 23:17:19c1ue hat geschrieben:08.12.2018 02:34:09Man könnte doch die x86-calls temporär umleiten, also eine Art Kompatibilitätslayer im Kernel, der diese calls in RISC übersetzt.
Sowas willst Du nicht. Wirklich nicht. Eine zusätzliche Abstraktionsschicht würde hier nur unnötige Kosten verursachen. Kosten im Sinne von "sehr langsam machen". Grade im Kernel will man keine zusätzlichen Umwege.
Siehe Transmeta, man hätte z.B. für Erweiterungen des x86-Befehlssatzes nur den Umsetzer erweitern brauchen. Hardwarefehler wie Spectre hätte man in Software angehen können. Allerdings schützt einen das nicht vor Hardwarefehlern im eigenen RISC/VLIW-Design. Und, wenn man Hardwarefehler durch Software stopft, wie es Intel mit Microcode macht, kann das auch Auswirkungen in der Geschwindigkeit haben.c1ue hat geschrieben:08.12.2018 02:34:09Außerdem könnten auf diese Weise - Quellcodebereinigungen in allen FOSS Projekten vorausgesetzt - diverse Sicherheitslücken von Grund auf angegangen werden.
Re: Warum nicht gleich für RISC programmieren?
Mein Gedanke ist: Wenn sämtliche Software sowieso komplett auf RISC angepasst würde, dann wäre die Wahrscheinlichkeit, dass versehentliche Backdoors im Quellcode gefunden würden, hoch, oder eben (bedingt durch die "neue Architektur") laufen die Backdoors dann ins Leere.eggy hat geschrieben:09.12.2018 23:17:19Und warum glaubst Du, dass Sicherheitslücken durch die Verwendung von RISC Instruktionen seltener auftreten? Oder hab ich Dich falsch verstanden?
Wir erleben gerade die letzte Ruhe vor dem Sturm. Genießen wir sie, solange es noch geht
Re: Warum nicht gleich für RISC programmieren?
Eher wahrscheinlich: es werden beim "eben mal kurz umschreiben" noch viel mehr neue Lücken eingebaut.c1ue hat geschrieben:17.12.2018 23:21:38Mein Gedanke ist: Wenn sämtliche Software sowieso komplett auf RISC angepasst würde, dann wäre die Wahrscheinlichkeit, dass versehentliche Backdoors im Quellcode gefunden würden, hoch, oder eben (bedingt durch die "neue Architektur") laufen die Backdoors dann ins Leere.
Re: Warum nicht gleich für RISC programmieren?
Umgeschrieben werden müssten in erster Linie Compiler und ’ne Handvoll Kram, der nicht portabel geschrieben wurde; alles andere würde nur neu kompiliert, oder, im Fall von Scripten, einfach direkt übernommen werden. Es gibt ja ganz Debian für PowerPC und diverse ARM-Versionen. Sind beides RISC-Sachen. Mir wäre nicht bekannt, dass bei deren Erstellung irgendwelche Sachen gefunden worden wären, die bei x86/64 übersehen wurden.c1ue hat geschrieben:17.12.2018 23:21:38Wenn sämtliche Software sowieso komplett auf RISC angepasst würde, dann wäre die Wahrscheinlichkeit, dass versehentliche Backdoors im Quellcode gefunden würden, hoch, oder eben (bedingt durch die "neue Architektur") laufen die Backdoors dann ins Leere.