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    [from the cache]
©2003-2011 Jasper Spaans