News Snapdragon X Elite mit Oryon-CPU: Dieser Chip soll Apple und Intel das Leben schwer machen

calluna schrieb:
Nein, unter einem 64 Bit Betriebssystem und 64 Bit-Anwendungen führt eine "x86-CPU" keine Befehle aus dem x86-Befehlssatz aus...
... ist klar. Du weißt schon, dass viele der Basisbefehle aus dem x86 auch heute noch immer verwendet werden - also "ISA"-Technisch? Nur dass diese entsprechend der Wortbreite angepasst sind im Maschinencode.

Mit x86_64 wurde kein vollständig neuer Befehlssatz erschaffen. x86_16, x86_32 und x86_64 teilen sich sogar bei den "Kernbefehlen" sogar noch dieselben Opcodes! Der Mode entscheidet nur dann, welche Register verfügbar sind und welche Wortbreite die Register haben.

Deine Aussage ist also weitgehend falsch, natürlich führt eine x86-CPU x86 Befehle aus, nur bestimmt der Mode, ob es 16 Bit, 32 Bit oder 64 Bit sind und welche Fähigkeiten dann jeweils zur Verfügung stellen und wie nachfolgende Teile ggf. interpretiert werden müssen.
 
  • Gefällt mir
Reaktionen: calluna, eSportWarrior und sikarr
DevPandi schrieb:
natürlich führt eine x86-CPU x86 Befehle aus, nur bestimmt der Mode, ob es 16 Bit, 32 Bit oder 64 Bit sind und welche Fähigkeiten dann jeweils zur Verfügung stellen und wie nachfolgende Teile ggf. interpretiert werden müssen.
Ist die 16Bit Funktionalität denn noch gegeben? Aus Windows ist es ja schon vor vielen Jahren geflogen aber könnte die CPU das noch wenn man ein passendes OS hätte (Treiberproblematik mal aussenvor)?
 
sikarr schrieb:
Ist die 16Bit Funktionalität denn noch gegeben? Aus Windows ist es ja schon vor vielen Jahren geflogen aber könnte die CPU das noch wenn man ein passendes OS hätte (Treiberproblematik mal aussenvor)?
Ja, theoretisch kannst du sogar heute noch ein MS-DOS auf einer Raptor-Lake-CPU oder einem Zen 4 System starten.

Intel hat das Streichen des 16-Bit und 32-Bit Modus dieses Jahr langsam zu einem Thema gemacht, womit dann DOS, aber auch die frühen NT-Kernel wirklich Geschichte werden würden.

Es geht bei beiden dabei primär um die "Bootmodi", die auch heute noch dazu führen, dass der Bootvorgang auf der Plattform relativ lange dauert, da man erst mal im 16-Bit Realmode startet. Es geht dann auch in den Protected und in den Long-Mode.
 
  • Gefällt mir
Reaktionen: Grimba und sikarr
sikarr schrieb:
Ist die 16Bit Funktionalität denn noch gegeben?
Installier dir ein Windows 10 in der 32bit Variante, und du kannst wieder 16 Bit Anwendungen ausführen. Es ist aus der 64Bit Variante geflogen, die 32er kann es meines Wissens noch. Auf einer aktuellen x86 CPU kannst du sogar MS-DOS installieren. Ob das am Ende ein gutes Erlebnis wird, sei dahingestellt. Aber abwärtskompatibel bis in museumsfähige Softwarezeitalter sind die nominell alle. Das ist ja Feature und Altlast zugleich.
 
  • Gefällt mir
Reaktionen: BAR86, eastcoast_pete, sikarr und eine weitere Person
Grimba schrieb:
Installier dir ein Windows 10 in der 32bit Variante, und du kannst wieder 16 Bit Anwendungen ausführen.
Ich dachte WinXP war das letzte OS was noch 16Bit Code ausführen konnte?

Habs selber gefunden.
Die 32bitter konnten es noch bis Win10 weil noch ein 16Bit Emulator Filter für 16Bit Code vorhanden war. Der fehlt aber den 64bitern seit es sie gibt.

Nativ 16Bit Code konnten nur die Windows 9x und davor, NT brauchte schon den Emulator.
 
Zuletzt bearbeitet:
Nee, aber mit XP haben sie es dann gesplittet, XP konnte 32 und 16bit. XP 64 konnte auch schon keine 16 Bit Software mehr, aber noch 32bit. Und das haben die afaik bis 10 so durchgezogen.
Nativ 16Bit Code konnten nur die Windows 9x und davor, NT brauchte schon den Emulator.
Naja, alles <= Me war ja auch schlicht und ergreifend einfach DOS :)

NT brauchte den Emulator, weil man eben diesen Brocken nicht mehr mit sich rumschleppen wollte und einen ganz neuen Unterbau entwickelt hat.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: sikarr
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: cha0shacker und sikarr
DevPandi schrieb:
Intel hat mit AVX10 sowie APX hier bereits zu Teilen die richtigen Erweiterungen in Petto, die einige der Limitierungen und Problemen der x86-ISA weitgehend "ausmerzen". Klar, wichtig ist hier für Intel, dass auch AMD zeitnah mitzieht, doch die Hauptlimitierungen der ISA werden damit angegangen.
AVX10 ist ja in erster Linie eine Zusammenfassung der CPUID feature flags, wenn ich es richtig sehe.
Und auch bei APX geht es, wenn ich es richtig verstanden habe, ausschließlich um die AVX-Register. Klar, man kann dann alte AVX/AVX2-Programme einmal neukompilieren und nutzt dann automatisch die 16 zusätzlichen Register, ohne die Abwärtskompatiblität zu AVX/AVX2 aufzugeben. Das ist alles schön und gut, aber für Programme ohne AVX bringt es nichts?!

Das Problem ist AVX selbst. Alle paar Jahre kommt ein neues feature set und die Anpassung der Software ist eben nicht immer trivial, wenn man Abwärtskompatiblität wahren will. Deswegen wird es meines Wissens vor allem in spezieller Software eingesetzt, wo es enorme Leistungssprünge ermöglicht. Die meisten Brot- und Butterprogramme werden die Komplexität aber wohl eher vermeiden wollen und Distributoren wollen auch nicht x verschiedene binaries ausliefern, ... Sicherlich kann AVX10 helfen, aber dann gibt es trotzdem noch Problemstellungen, die gar nicht oder nur kaum von SIMD-Befehlen profitieren.

Ich sehe das alles also etwas kritischer. Aber ich lasse mich gerne eines Besseren belehren ;)

sikarr schrieb:
Ist die 16Bit Funktionalität denn noch gegeben?
Kurz gesagt: Ja.
sikarr schrieb:
Ich dachte WinXP war das letzte OS was noch 16Bit Code ausführen konnte?
Zumindest für die 32-Bit-Version gilt das. Es ist eben etwas komplizierter. Die Abwärtskompabilität ist aber immer nur "eine Stufe" gegeben.

Bei AMD64 gibt es zwei Modi, den legacy mode und den long mode.
Im legacy mode hast du im Grunde einen 32-bittigen x86-Prozessor mit real mode (16 Bit) und protected mode (32 Bit). Ohne weiteres Zutun vom OS (oder UEFI, oder dem Bootloader) bist du immer zuerst im legacy mode. Da kannst du auch ein 16-Bit-OS nutzen, oder eben ein 32-Bit-OS, genau wie eben bei klassischen i386-Prozessoren. Genau wie dort ist es auch möglich, 16-Bit-Programme im protected mode auszuführen, dafür gibt es den Virtual-8086-Mode. Kompliziert, oder? So war das aber schon seit dem 386 üblich...

Wenn das OS (oder UEFA/der Bootloader) proaktiv in den long mode geht (was jedes 64-Bit OS tut), dann sieht die Welt etwas anders aus. Hier gibt es den normalen 64-Bit-Modus und den compatiblity mode. Der Betriebssystem muss letzteren unterstützen und ermöglicht die Ausführung von 32-Bit-Programmen in einer protected mode-Umgebung, die recht kompliziert in die AMD64-Architektur eingebettet ist (was insb. das Paging betrifft) und für das jeweilige Programm vom OS aktiviert werden muss.

Diese Komplexität hatte den Weg für den Erfolg von AMD64 geebnet, weil man erstmal ohne Einschränkungen genau seine Software weiterverwenden konnte (legacy mode). Gleichzeitig konnte man aber auch auf ein 64-Bit-OS umsteigen, sobald man keine 16-Bit-Software (mehr) eingesetzt hat.

Intel wollte ja damals schon mit Itanium auf eine neue Architektur umsteigen, die konnte den x86 protected mode aber nur emulieren. Ergo hätte alles neu gemusst: Betriebssystem, Treiber, performancekritische Programme. War daher kein Erfolg und man hat es aufgegeben und stattdessen AMD64 adaptiert.

Die alten Zöpfe nun trotzdem loszuwerden ist auch Teil eines Intel-Projekts, das hat @DevPandi ja schon angesprochen. Der legacy-Mode wird dann gestrichen, was nicht ganz trivial ist, weil alle x86 im real mode starten müssen, um BIOS-kompatibel zu sein. Aber die wenigsten werden heute noch 32-Bit-Betriebssysteme oder älter auf topmoderner Hardware einsetzen, deshalb ist es grundsätzlich sinnvoll.
 
Web-Schecki schrieb:
AVX10 ist ja in erster Linie eine Zusammenfassung der CPUID feature flags, wenn ich es richtig sehe.
Ja und Nein zur gleichen Zeit.

Du hast natürlich recht, dass hier AVX1 - AVX512 "zusammengefasst" wird, gleichzeitig räumt Intel hier aber auch auf und trennt die Wortbreite von den Befehlen. Wir haben aktuell ja die lustige Situation, dass AVX512-Erweiterungen erneut implementiert werden mit 128 und 256 Bit-Modus.

Intel trennt bei AVX10 die "Wortbreite" von den Befehlen und ebenso auch von der Hardware-Ebene, was sogar sehr sinnvoll ist und in der Form an SVE1/SVE2 in der Arm-ISA erinnert. Jetzt können viele Befehle vom Compiler mit 128 Bit, 256 Bit und 512 Bit genutzt werden und auf Hardwareebene kann man sich überlegen 128 Bit-SIMD, 256 Bit-SIMD oder 512 Bit-SIMD einpflegen.
Web-Schecki schrieb:
Und auch bei APX geht es, wenn ich es richtig verstanden habe, ausschließlich um die AVX-Register.
Nein, das hast du in dem Fall falsch verstanden. AVX512 brachte 32 "fp"-Register, so wie AMX bei den 32 bleibt. APX erweitert nun die Register im "Int"-Teil von 16 auf 32, weil das entsprechende Vorteile bringt. Ist auch der Beschreibung zu entnehmen. "Intel® APX doubles the number of general-purpose registers (GPRs) from 16 to 32. This allows the compiler to keep more values in registers; as a result, APX-compiled code contains 10% fewer loads and more than 20% fewer stores than the same code compiled for an Intel® 64 baseline.2 Register accesses are not only faster, but they also consume significantly less dynamic power than complex load and store operations."
- Quelle https://www.intel.com/content/www/u...ical/advanced-performance-extensions-apx.html
 
  • Gefällt mir
Reaktionen: Web-Schecki
Mal schauen zu welchen Preis, denn die SoC von ARM sind ganz schön teuer geworden.
 
SVΞN schrieb:
Weil es symbolisch ist für das wohin x86 steuert. Darüber gibt es mittel- und langfristig auch kaum noch abweichende Meinungen.

Arm und in bestimmten Bereichen V-RISC werden x86 schon sehr bald ziemlich zu schaffen machen und letztlich ablösen.

Ich sehe da auch gar kein Problem drin. Nur Nostalgiker klammern sich an x86, aber da ist so ziemlich die Luft raus.

Das wird noch nicht morgen der Fall sein, aber das Ende ist meiner Meinung nach bereits absehbar.
Nichts steht der Ko-Existenz im Wege. Für bestimmte Aufgaben sind analoge Rechner auch besser als digitale Rechner. Für jede Aufgabe das beste 👏
 
incurable schrieb:
Qualcomm als Reiseagentur für Journalisten. Natürlich nur, weil solche Fachinformationen nur im Inselparadies am anderen Ende der Welt vollständig und korrekt übermittelt werden können.
Naja, man will ja auch dass möglichst viele Journalisten kommen und berichten... Und es ist "natürlich" dass man sich einen schönen Ort sucht.

Auf der anderen Seite ist Hawaii aber durchaus logisch wenn man bedenkt dass QC eine US Firma ist deren Hauptmärkte mittlerweile eben in Asien liegen. Auch die USA, klar, aber da ist der Apple-Anteil afaik höher am market share.
Asien ist aber gigantisch für QC - und Hawaii eben der US Bundesstaat welcher am nächsten an diesem Markt dran ist.
Dementsprechend kurze Reisezeit (und geringere Flugkosten).
 
Grimba schrieb:
Installier dir ein Windows 10 in der 32bit Variante, und du kannst wieder 16 Bit Anwendungen ausführen. Es ist aus der 64Bit Variante geflogen, die 32er kann es meines Wissens noch. Auf einer aktuellen x86 CPU kannst du sogar MS-DOS installieren. Ob das am Ende ein gutes Erlebnis wird, sei dahingestellt. Aber abwärtskompatibel bis in museumsfähige Softwarezeitalter sind die nominell alle. Das ist ja Feature und Altlast zugleich.
Wobei man dabei (DOS installieren) allerdings schnell Probleme mit den nicht vorhandenen Treibern für WiFi usw bekommt. Allerdings gibt es ja Software, v.a. solche die speziell für bestimmte Messgeräte, altbewährte CNC Maschinen usw, die nur für MS-DOS bzw Win95/98 geschrieben wurde, und wenn die Maschinen weiter genutzt werden sollen, führt manchmal an dem Original OS kein Weg vorbei.
Es gibt auch aus diesem Grund Firmen, die sich darauf spezialisiert haben, neue oder runderneuerte alte PCs zu verkaufen, die MS DOS etc "können", und auch zB noch parallele und RS-232 serielle Ports haben. Ans Netz (Internet) würde ich sowas aber schon aus Sicherheitsgründen nie lassen.
Ergänzung ()

Einige der Kommentare zur Schwupdizität von Mac M1, M2 vs. Windows PCs übersehen auch geflissentlich, daß sehr viel Geschwindigkeit durch Dinge wie SSDs statt HDDs gewonnen wurde. Macht einen Riesenunterschied! Da muss man eben schon Computer aus dem selben Jahrgang, in ungefähr derselben Preisklasse und mit zumindest ähnlicher Speichertechnik vergleichen damit sowas passt.
 
Zuletzt bearbeitet:
Salamimander schrieb:
Mit 75%* mehr Kernen als der M2 50% schneller. Eine Kunst :D


*Damit auch die Klugscheißer verstehen was ich meine:
4 P-Cores + 4 E-Cores ˜= 6 effective P-Cores
Naja "core" ist auch nicht gleich "core". Am Ende stellt sich auch die Frage, wie groß diese Cores sind. Es kann auch sein, dass die relativ klein sind und gut mit dem Takt skalieren. Das würde auch erklären, wieso es 12 "gleiche" chips sind. Also lieber mal abwarten :)

=> 4 P-Cores + 4 E-Cores ˜= 6 effective P-Cores
Wie kommt man auf das? Ich dachte das ist ja das tolle an den 4E-Cores, dass Multithreading besser ausfällt.
 
McFritte schrieb:
Ok, wenn du der Meinung bist

Geekbench 6 (Single-Core)

Anhang anzeigen 1412694


Geekbench 6 (Multi-Core)

Anhang anzeigen 1412695
Ja, die IPC ist deutlich gestiegen und der N100 taktet auch höher.
Eigentlich erstaunlich wie flott die Dinger sind für die paar Watt.

Ich müssts mir mal im Surface Go 4 ansehen, aber das hat nur 8GB Ram, ich hätte gerne ein Upgrade, mein Go 3 ist sehr zäh manchmal
 
  • Gefällt mir
Reaktionen: eastcoast_pete
Zusammenfassung des AI Events, auch mit SC-Pimmelvergleichen:

Schneller als ein M2 Max oder Intel i9-13irgendwasHX
Ergänzung ()

McFritte schrieb:
Ok, wenn du der Meinung bist

Geekbench 6 (Single-Core)

Anhang anzeigen 1412694


Geekbench 6 (Multi-Core)

Anhang anzeigen 1412695
Ohne Frage ist der N100 (und auch der N200 des Surface Go 4) ein relatives Rechenmonster.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: JohnWickzer
Wenn der auf Linux läuft, dann wäre er ev. interessant für mich als Mini-PC.
Ganz sicher nicht als Notebook.

Abgesehn davon ist ein gutes Ergebnis mit Geekbench für mich kein Argument. Real world performance zählt mehr als syntethische Benches.
 
Zuletzt bearbeitet:
Gerithos schrieb:
Das hier ist kein ARM
Da dieser chip den gleichen Befehlssatz nutzt, dachte ich mir das mal so zu nennen. Ich denke auch, dass die Vorteil eines Arm-Prozessors vorhanden sein werden. Wäre es richtig gewesen, wenn ich arm basieren geschriben hätte, wie bei den apple M chips? So tief bin ich in dem Thema leider nicht drin, weshalb ich da keine klare Grenze ziehen kann.
 
Zurück
Oben