gleicher code auf unterschiedlicher hardware



  • dot schrieb:

    Ich kann dir nur empfehlen die Frage nochmal zu lesen und zu versuchen zu verstehen warum deine Aussagen absolut nichts damit zu tun haben bevor du dich hier noch weiter lächerlich machst...

    Oh wow, ich spüre mich von der Welle der rationalen Gegenargumente glatt überrollt.

    Wikipedia schrieb:

    A hardware abstraction layer (HAL) is an abstraction layer, implemented in software, between the physical hardware of a computer and the software that runs on that computer. 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.

    Jetzt bring mal deine eigenen Argumente, bin ich mal gespannt. 😉



  • 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...



  • 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.

    Alle Applikationen kommunizieren mit den Hardware-Ressourcen (z.B.: CPU) über das Betriebssystem.

    Wiki schrieb:

    Kernel
    The kernel sits between the HAL and the Executive and provides multiprocessor synchronization, thread and interrupt scheduling and dispatching, and trap handling and exception dispatching



  • @AP0LL0: Wenn ich eine ausfuehrbare Datei habe, die die Erweiterung SSE4 benutzt, mein Prozessor aber kein SSE4 hat, dann wird sie zweifelsohne abstuerzen (im guenstigsten Fall).

    Alle Applikationen kommunizieren mit den Hardware-Ressourcen (z.B.: CPU) über das Betriebssystem.

    Nein, das ist falsch. Du missinterpretierst die Fakten auf wikipedia.



  • knivil schrieb:

    @AP0LL0: Wenn ich eine ausfuehrbare Datei habe, die die Erweiterung SSE4 benutzt, mein Prozessor aber kein SSE4 hat, dann wird sie zweifelsohne abstuerzen (im guenstigsten Fall).

    Alle Applikationen kommunizieren mit den Hardware-Ressourcen (z.B.: CPU) über das Betriebssystem.

    Nein, das ist falsch. Du missinterpretierst die Fakten auf wikipedia.

    Dass musst du mir jetzt mal beweisen.



  • Welche der Aussagen? Fange aber bitte selbst bei meinem SSE4-Beispiel an. Wie soll ein Programm, das SSE4 benutzt, auf einer CPU laufen, die kein SSE4 zur Verfuegung stellt?



  • knivil schrieb:

    Welche der Aussagen? Fange aber bitte selbst bei meinem SSE4-Beispiel an.

    Nein, das Code-Execution nicht vom Kernel/HAL gemacht wird.



  • Nur um das klarzustellen: In diesem Forum hier tummeln sich großteils Leute die Ahnung von ihrem Handwerk haben und keine Scriptkiddies die man mit Büchern über Treiberprogrammierung und ein paar Buzzwords die man irgendwo mal aufgeschnappt hat beeindrucken kann. Wir wissen was ein HAL ist und wie ein Betriebssytem funktioniert, viele hier haben sicher selbst schon an dem ein oder anderen OS Kernel Hand angelegt. Ich wiederhole einfach mal meine Empfehlung an dich einen Schritt zurück zu treten und die ursprüngliche Frage in diesem Thread zu lesen. Aber wenn du unbedingt alles auf OS Kernel Ebene diskutieren musst, folgender Hinweis: Die Kernelkomponente die mit der Frage hier am ehesten zu tun hat ist der Loader und nicht der HAL.

    Ansonsten hätt ich vielleicht mal eine Buchempfehlung für dich, gibts sogar auf deutsch...



  • dot schrieb:

    Nur um das klarzustellen: In diesem Forum hier tummeln sich großteils Leute die Ahnung von ihrem Handwerk haben und keine Scriptkiddies die man mit Büchern über Treiberprogrammierung und ein paar Buzzwords die man irgendwo mal aufgeschnappt hat beeindrucken kann. Wir alle Hier wissen was ein HAL ist und wie ein Betriebssytem funktioniert, viele hier haben sicher selbst schon an dem ein oder anderen OS Kernel Hand angelegt. Ich wiederhole einfach mal meine Empfehlung an dich einen Schritt zurück zu treten und die ursprüngliche Frage in diesem Thread zu lesen. Aber wenn du unbedingt alles auf OS Kernel Ebene diskutieren musst vielleicht folgender Hinweis: Die Kernelkomponente die mit der Frage hier am ehesten zu tun hat ist der Loader und nicht der HAL.

    Ach ich soll mich nicht von Büchern, die von langjährig erfahrenen Treiber-Entwicklern geschrieben wurden, nicht beeindrucken lassen, aber vom TypenXYZ auf ForumABC doch?

    Wenn du so ein Profi bist, was hast du denn gelesen. Welche Dokumente hast du die mein Wissen widerlegen können?



  • Ich hab es nicht notwendig mich hier mit irgendwelchen Büchern die ich gelesen hab zu profilieren. 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...



  • 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.


Anmelden zum Antworten