gleicher code auf unterschiedlicher hardware
-
AP0LL0 schrieb:
Nein, das Code-Execution nicht vom Kernel/HAL gemacht wird.
Eben, genau das versuchen wir dir hier die ganze Zeit klarzumachen...
-
Um es mal zusammenzufassen! Die Antwort lautet auf:
muesste man nicht pro cpu eine cpu spezifische exe erstellen?
Nein, wenn die Ziel-CPUs den gleichen Befehlssatz bereitstellen was bei AMD und Intel der Fall ist. Sollen spezielle Features der einzelnen CPUs ausgenutzt werden und nicht oder anders durch die andere CPU angeboten wird, dann muessen zwei unterschiedliche Programme erstellt werden.
Ich frage mich immer noch, was das ueberhaupt mit HAL zu tun hat.
-
knivil schrieb:
Ich frage mich immer noch, was das ueberhaupt mit HAL zu tun hat.
nichts...
-
dot schrieb:
Wenn du es tatsächlich so drauf anlegst dich lächerlich zu machen dann bitte, go ahead, ich werd nichtmehr versuchen dich vor dir selbst zu bewahren...
Du hast immer noch keinen Verweis aufgebracht der mich widerlegt. Du alberst hier rum wie der allerletzte Code-König, hast aber wahrscheinlich nen Pups von ner Ahnung. Und jetzt wo du langsam verstehst dass ich ohne valide Gegenargumente und einen validen Verweis (den es geben würde, hättest du denn recht) nicht aufgebe ,willst du einen auf: "Oh ich lasse diesen armen Irren einfach mal so stehen. Ach bin ich heute wieder schlau" machen.
traurig.
-
Hast du dich eigentlich nur zum Trollen registriert?
-
AP0LL0 schrieb:
Du hast immer noch keinen Verweis aufgebracht der mich widerlegt.
Doch hab ich, wenn du dir die Mühe gemacht hättest meine Postings zu lesen und zu verstehen wär dir das mittlerweile auch klar.
Aber nochmal zusammengefasst:
Bei dem von dir angesprochenen HAL handelt es sich um einen Teil eines OS Kernels dessen Zweck es ist den Kernel Source Code möglichst portabel zu halten, d.h. möglichst viel des Kernel Source Code auf möglichst vielen verschiedenen Architekturen zu verwenden (in den von dir verlinkten Quellen steht übrigens genau das und nichts andres). Eben wie der Name schon sagt eine Abstraktionsschicht. Mit der Portabilität von Binaries (um die es hier geht) hat das rein gar nichts zu tun. Eine x86 Binary kann ich auf jeder x86 CPU ausführen, egal ob die von Intel oder AMD ist, da es eben die selbe Architektur ist. Aber eine IA64 Binary kann ich nicht auf einer x86 CPU ausführen, egal wieviele HAL mein OS Kernel noch haben mag...
-
knivil schrieb:
Hast du dich eigentlich nur zum Trollen registriert?
Wollen wir mal für ihn hoffen dass das so ist
-
dot schrieb:
AP0LL0 schrieb:
Du hast immer noch keinen Verweis aufgebracht der mich widerlegt.
Doch hab ich, wenn du dir die Mühe gemacht hättest meine Postings zu lesen und zu verstehen wär dir das mittlerweile auch klar.
Aber nochmal zusammengefasst:
Bei dem von dir angesprochenen HAL handelt es sich um einen Teil eines OS Kernels dessen Zweck es ist den Kernel möglichst portabel zu halten, d.h. möglichst viel des Kernel Source Code auf möglichst vielen verschiedenen Architekturen zu verwenden. Eben wie der Name schon sagt eine Abstraktionsschicht. Mit der Portabilität von Binaries (um die es hier geht) hat das rein gar nichts zu tun. Eine x86 Binary kann ich auf jeder x86 CPU ausführen, egal ob die von Intel oder AMD ist, da es eben die selbe Architektur ist. Aber eine IA64 Binary kann ich nicht auf einer x86 CPU ausführen, egal wieviele HAL mein OS Kernel noch haben mag...Ist ein einfacher Wikipedia-Link zuviel verlangt?
-
AP0LL0 schrieb:
Ist ein einfacher Wikipedia-Link zuviel verlangt?
Hier bitte: http://en.wikipedia.org/wiki/Hardware_abstraction_layer
Und ja ich weiß du hast den Artikel schon zitiert, darum hab ich da ja auch folgendes drauf geantwortet:
dot schrieb:
Die Argumente lieferst du dir eh schon selber:
AP0LL0 schrieb:
Wikipedia schrieb:
Its function is to hide differences in hardware from most of the operating system kernel, so that most of the kernel-mode code does not need to be changed to run on systems with different hardware.
Aber auch der HAL in einem OS Kernel wird zwischen x86 CPUs von Intel und AMD keinen großen Unterschied machen da beide eben die selbe Architektur implementieren wie knivil schon gesagt hat. Der Sinn von einem HAL ist es eben architekturspezifische Dinge möglichst vom restlichen Code zu isolieren um die Portierung auf eine andere Architektur möglichst einfach zu machen. Mit der ursprünglichen Frage hat das alles nach wie vor nichts zu tun...
Lies den Artikel diesmal also vielleicht aufmerksam und ganz durch...
-
AP0LL0, bist du besoffen oder was?
Der HAL abstrahiert Zugriff auf den Interrupt Controller und so Scheiss, nicht Zugriff auf die CPU.
Die CPU muss also schonmal weitestgehend kompatibel sein.
-
dot schrieb:
AP0LL0 schrieb:
Ist ein einfacher Wikipedia-Link zuviel verlangt?
Hier bitte: http://en.wikipedia.org/wiki/Hardware_abstraction_layer
Wer ist hier der "Troll", eh? Siehe es doch ein, der Grund warum Programme die auf Windows Kompiliert wurden auf allen Prozessor-Architekturen läuft ist die HAL und der Microkernel. Ich lass mir jetzt auch nichts mehr erzählen.
Schon alleine zu behaupten das Applikationen autonom abseits des Betriebssystems agieren und Prozessor-befehle ausführen ist Schädel-knackend.
-
LOL, mehr fällt mir dazu echt nimmer ein...
-
dot schrieb:
LOL, mehr fällt mir dazu echt nimmer ein...
LOL
Deine Internetakronyme kannst du dir sparen.
-
AP0LL0 schrieb:
Siehe es doch ein, der Grund warum Programme die auf Windows Kompiliert wurden auf allen Prozessor-Architekturen läuft ist die HAL und der Microkernel.
Programme die auf Windows kompiliert wurden laufen nicht auf allen Prozessor Architekturen sondern, wie auch Programme die auf jedem anderen OS kompiliert wurden, nur auf der Architektur für die sie kompiliert wurden.
Wenn dus mir nicht glaubst lad ich dich ein es einfach auszuprobieren.
AP0LL0 schrieb:
Schon alleine zu behaupten das Applikationen autonom abseits des Betriebssystems agieren und Prozessor-befehle ausführen ist Schädel-knackend.
Genau so ist es aber.
Wenn dus mir nicht glaubst solltest du ein Buch über Betriebssysteme lesen (und verstehen).
Ansonsten hab ich dem nichtsmehr hinzuzufügen...
-
AP0LL0 schrieb:
Siehe es doch ein, der Grund warum Programme die auf Windows Kompiliert wurden auf allen Prozessor-Architekturen läuft ist die HAL und der Microkernel.
Wahnsinn, was so ein HAL und Microkernel für Kräfte bei einem Compiler freisetzen. In Zukunft werd ich einfach mal meine VC++ Solutions, die mit x86 builden, locker flockig auf 'ner RISC-Möhre laufen lassen
-
Vorher aber HAL 2000 installieren und gut ist.
-
Habe mir jetzt nicht jeden einzelnen Beitrag durch gelesen. Und ich bin auch kein x86-Kenner. Aber ich kenne mich mit ARM und RISC OS aus. Und da weiß ich, das es das gibt, was Apollo beschreibt.
ARM CPUs haben z.B. selten eine FPU. Wenn ich auf einem non-FPU ARM eine FP-Instruction nutze, wird auf dem ARM erstmal eine Exception geworfen und eine bestimmte Speicherstelle aufgerufen, auf der man vorher einen Vektor verbiegen kann. Und dann kann man z.B. einen FPU-Emulator anspringen lassen. Den Rest kann sich jeder selber denken.
Jedenfalls kann ich so auf ARM Prozessoren jede nicht in Hardware implementierte Instruktion auf in Software implementierte Instruktionen umbiegen lassen. Und da man einen Treiber jeder zeit austauschen kann, kann ich auch fehlende Prozessor-Features emulieren.
Das ist jedenfalls die Erfahrung die ich mit ARM und RISC OS gemacht habe, und diese Kombination gibt es schon seit 1987! Wie es mit x86 und NT läuft weiß ich nicht. Aber ich kann mir nicht vorstellen, das ein x86 sowas nicht kennt. Und so wird es wohl auch mit SSE & Co. laufen. Voraus gesetzt der Treiber ist wirklich vorhanden.
Was natürlich blödsinnig ist, ist komplett inkompatible Befehle ausführen zu wollen. Aber in dem Thread geht es ja um optionale Features, wie FPU, VFP, MMX, SSE, 3D Now usw.
-
ihr lasst euch hier aber von dem trollen
-
moment mal
für deine theorie, dass die programme wegen dem HAL auf allen architekturen laufen, müsste doch erstmal ein HAL für eben diese architekturen gegeben sein, oder nicht?!?
aber versuch windows mal auf meiner waschmaschine zu installieren und zum laufen zu bekommen...
wenn du das geschafft hast dann sollte es kein problem darstellen, dass deine programme dann auch auf ihr laufen...
(wobei mir persönlich in dem fall egal wäre ob per HAL oder direkt programmiert)
-
Skym0sh0 schrieb:
wenn du das geschafft hast dann sollte es kein problem darstellen, dass deine programme dann auch auf ihr laufen...
eben doch...
Artchi schrieb:
...
Sowas kann man über entsprechende Exception Handler auch auf x86 implementieren. Das wär eben nur wahnsinnig langsam und hat jetzt schon weder mit dem HAL (der selbst schon nichts mit der Frage zu tun hatte) noch mit der usprünglichen Frage was zu tun...
