RE: On the possibility of encoding a portable interpretable objectcode into Unicode

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Fri Mar 27 2009 - 02:25:37 CST

  • Next message: Rick McGowan: "Re: Old Hungarian at SC2/WG2"

    De la part de Jeroen Ruigrok van der Werven
    > -On [20090326 20:35], Leo Broukhis (leob@mailcom.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
    neural networks.

    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
    supervision.

    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
    application servers).

    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