Messages in this thread |  | | From | Systemkennung Linux <> | Subject | Re: Driver optimization. | Date | Mon, 1 Jul 1996 04:35:46 +0200 (MET DST) |
| |
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
|  |