>You must not have heard of IBM mainframes - one of the mainframe
>OSes is CALLED VM (Virtual Machine), and the S/3X0 hardware is fully
>virtualisable, so you can run any number of copies of the OS inside
>itself (even the Linux s390 port runs under VM).
One of the advantages of IBM hardware. Too bad other manuafturers don't
learn from them...
>I think the hypervisor is a made-up term, the "supervisor of supervisors
>(kernels)". I think what Alan means is that as long as the Linux kernel
>APIs are available, and the "CPU" can run x86 code from normal programs,
>the kernel itself can be running a totally different machine language.
It is a made-up term, but you hit the nail right on the head describing
it. What you describe here about the kernel not caring what
instructionsets the CPU supports, isn't this untrue? Ever tried to run a
binary compiled for PPC under x86? You get something an error message, eg:
zsh: exec format error
I think the kernel would have to know what instructionsets are available
on the CPU, but as far as what instructions each executable was compiled
with, it probably matters not.
>At one time (long ago) there was talk about an IBM PowerPC 635? which
>had a PPC core and a 386 core, and the 386 core was only for x86 program
>"emulation", but the OS would run under PPC. I think that Crusoe could
I believe IBM wanted to include this support under 608 CPU, but didn't.
The way I remember was a 486 core though...apparently they had some design
issues that halted the project.
>(does?) do this with Linux - with the kernel (maybe libraries too?)
>running
>in native mode, and the user code running either the (presumably slower)
>x86
>mode or the (presumably faster) native VLIW mode.
Although I don't know much about the Crusoe per se, I do know a little
about how it works, with the code morphing and whatnot. As far as anything
goes, sure, this is a great idea, and can be real fast...But I think in
the future what we want is a CPU that is 'intelligent' and actually morphs
its machine code dependant on what instructions it will use on a per
program basis. Although this would take one HELL of an operating system to
pull off, it _would_ be possible. Think about it... At the assembly level,
you can count the unique instructions used, and any decent overoptimizing
compiler could reduce large multiple-cycle instructions into many smaller
single-cycle instructions, build an assembler header of the instructions
that are to be used by that program, have the kernel send that header to a
protected region in on-cpu memory, and have a small instructionset
tailored to the program being run at the moment, (minimizing lookup time).
basically it would mean having the hardware adapt to the code, and not the
code adapt to the hardware. As far as plauseability of this idea, I really
couldn't say... it seems pretty far-fetched but I think that it would be
possible if a few decent cpu designers put their heads together...
>Whether Crusoe does this now, or in the future, I don't know. Maybe it
>is
>running x86 mode just to test that the x86 mode is very compatible
>(needed
>until Windows goes away) and it will slowly migrate to native VLIW mode
>as
>applications/compilers support it.
Face it, there are to many lemmings out there...windows isnt going to go
away anytime soon, so the slow x86 architecture isnt going to either.
just my 0.02 (mexican pesos, it aint worth much :P)
Kelsey Hudson khudson@ctica.com
Associate Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
-Kicking the computer solves all the problems. Just try it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:14 EST