From: Philippe Verdy (firstname.lastname@example.org)
Date: Fri Mar 27 2009 - 02:25:37 CST
De la part de Jeroen Ruigrok van der Werven
> -On [20090326 20:35], Leo Broukhis (email@example.com) wrote:
> >Is there "the" portable interpretable object code?
> I get flashbacks to UNCOL.
The earliest may be the Turing's Machine, and its language based on a finite
alphabet (or equivalently a range of integers or digits) and running in a
virtual machine (that was really virtual as it was impossible to build it
completely, given that it had infinite size. Today's computers are low
approximations of this machine, because they are bound to finite limits
(even if those limits are still growing exponentially after Moore's law).
But may be it was Blaise Pascal's calculator, the Pascaline, or the other
intermediate contributors to mechanical computing, that were described first
virtually before being ever built, like Leibniz and Reckoner?
Today these old machines can be simply emulated, just like we emulate most
Or was it the P-Code used in early versions of Pascal in a way that produced
more efficient programs than what compilers were able to produce before with
ALGOL... The P-Code has been used as long as compilers were not able to fine
tune the generated program for specific processors, it was used to simpify a
lot the development of compilers.
Some had predicted that with the progress of processors, we could avoid
producing P-code; but the opposite is happening: with the shrinking time of
life of architectures (not just the processors alone), softwares cannot
evolve so fast, and with the explosion of networking environments connecting
a lot of heterogeneous systems, the need to deploy the same software on ever
changing platforms militates for an increased used of virtual machines.
As it becomes now impossible to predict where the software will atually run
(because it will be the task of a networking OS to allocate the ressources
and schedule the software on them according to local constraints or
policies, maximum available resources and minimum software requirements) we
need now intermediate languages that can run on many environments but that
can be recompiled and tuned almost automatically without the need of humane
So the P-code is not dead. However the new development of compilers has
increased the nyumber of layers and this process is now too complex to
manage by a few programmers, and costs a lot with lots of people involved to
test it. So there are reallynot a lot of efforts that can be sustained to
develop an common VM. Today, two of them are competing: the Java VM (JVM)
and the CLR environment for .Net, that are capitalizig the most massive
budgets for the development of new applications (most of them running on
There are other competing VMs (including Parrot which is not known by many
except a frange of Python programmers, or the "V8" JScript engine developed
by Google for Chrome). But for now there's still not "THE" ultimate portable
VM for all needs.
If it existed, we would already have an ISO standard for it (just like we
have a ISO standard for OpenType, characters, scripts, metric systems, and
ISO standards regulating their use if necessary), and we could immediately
start abandonning all natively compiled programs.
But we can contour some features that this VM should support: strong
security mechanisms and multiple isolation levels; transparent deployment;
failsafe backup aith automatic recovery; plug-n-play for the added
resources; automatic topology building and discovery; automatic
reconfiguration of this topology; unlimited number of processors; unlimited
number of users, realms, identities; multiple processes, parallelism,
multithreading; resolution of time constraints; stability of the system
including during or after failure and recovery... Debuffingand monitoring
facilities. Pssibilities to control directly the scheduling or chreate
sub-scheduling of some groups using more restrictive deployment constraints
for the hardware nodes where the VM will run. And of course trnsparent to
programming languages and to user's locales (including natural languages and
scripts used in localizable resources).
We are still very far from these objectives. The bytecode used for the VM is
secondary; may be there will be the need for several bytecodes, one for each
abstraction layer in the final architecture. Many of the existing bytecodes
of tody will continue to evolve, they are not molded in bronze, and I don't
see te interest of asigning specific codepoints to abstract VM instructios
that will just be useful for possibly a couple of years.
This archive was generated by hypermail 2.1.5 : Fri Mar 27 2009 - 09:18:14 CST