lkml.org 
[lkml]   [1996]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Driver optimization.
    Date
    Hi,

    > On a similar note, I was speaking to a friend who is fairly familiar with
    > NT. He states that you can install NT 3.5/4.0 on computer A, a 586, and
    > also on computer B, a DEC alpha, and also computer C, a PowerPC RS/6000.
    >
    > Then you can go to a store and buy Word or Office for NT, and install the
    > same software on computer A and on computer B and on computer C.

    M$ delivers NT and their NT software compiled for Alpha, Intel, MIPS and
    PowerPC. No magic and no stone of wisdom involved.

    > Now I must admit this sounded really unlikely; after all, what kind of
    > binary format could be implemented to generate code that is acceptable to
    > a DEC Alpha, a Pentium, and a PowerPC?

    See below.

    > My friend attributed this to a "Hardware Abstraction Layer", which I
    > simply read as being a microkernel based approach to solving processor
    > and platform differences, and what came to mind was mklinux running on a
    > PowerMac....

    Actually NT's has something that is called Hardware Abstraction Layer "HAL".

    > Yet, when I got an mklinux box up, and transfered an x86 binary to it, and
    > tried to run it, no go!
    >
    > % file foobar
    > foobar: ELF 32-bit LSB executable i386 (386 and up) Version 1
    >
    > What is it that NT has supposedly implemented?

    The HAL is a layer that abstracts out things like how to enable/disable
    certain interrupts, handle the CPU's caches, generate spinlocks, handle
    the realtime clock, handle certain lowlevel interrupt stuff etc. In
    short it's a kind of a driver for the CPU and the motherboard hardware
    itself.

    The HAL's isn't intended to eleminate the difference between different
    CPU architectures.

    > What does it take to do "binary compatibility" across platforms? (i.e.
    > what does it take to run the *same* binary on x86, 68k, alpha, ppc?

    Just five of many options available:

    - interpreted languages
    - emulation of another CPU. This has horrible impact to performance.
    - Recompiling. Ok, this isn't binary compatibility.
    - Building fat binaries that contain the code for multiple CPU families
    in just one file.
    - Something like the HP/UX variant of symbolic links that is currently
    being discussed on this list would give a elegant solution.

    > It would be nice to be able to say, "hey, if you install Linux on your
    > machine, it will run all the code for Linux, whether compiled on PowerMac
    > or on a Pentium"...
    >
    > How can a microkernel approach be modified to allow binary compatibility?

    Binary compatibility has nothing to do with microkernels.

    > Is this an appropriate thing to have on a wish-list for 2.1?
    > Hopefully, NT on a PowerPC or a DEC box isn't *emulating* x86 code;
    > otherwise we see the horrendous performance you see on a PowerMac trying
    > to execute 68k code!

    For shure not.

    > It appears to me that NT has a technical advantage if what my friend says
    > is true?

    Everything that exists for NT is emulation software that allows to run
    x86 DOS/Windows software on RISC NT. The price you have to pay is bad
    performance. I won't pay.

    Ralf


    \
     
     \ /
      Last update: 2005-03-22 13:37    [W:3.213 / U:0.248 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site