Re: Ada and JVM? Why not AdaVM?

["chris.danx" <chris.danx@ntlworld.com>]

Hi,
    I can think of a few problems with this approach(e.g. tasking in Ada,
though maybe i'm wrong).  What about a hybrid approach?  Generate a
structure similar to a parse tree, but with cut the work of the secondary
(JIT) compiler, by describing the program as a graph.  I don't have much
experience with graphs but i think it would be better (if i'm not, I'm sure
someone will correct me).

One of my ideas was to allow runnable code to be executed virtually in the
IDE, allowing testing.  So for example i could write the following,

    procedure x is
    begin
        ...
        ...
        while not finished loop
            -- do something;
        end loop;
        ...
        ...
    end x;

I could then test the while loop with the neccessary input and watch what it
was doing from the IDE.  I've seen something similar in Smalltalk but it's
not really the same as what i have in mind.  If i used a hybrid structure
then perhaps this could make this possible.  The 'while loop' would be
described by a graph-like structure, and i would supply inputs via the IDE.
The environment could then allow the loop to be executed by a VM.  Once it's
finished and tested it goes to the native hardware, though the structure
could be used on another machine with suitable translator.

I also want to experiment with a system to allow updates to programs
(perhaps, at runtime) without the source.  I know these capabilities aren't
features of the  Ada 95 RM.  I want to know if they'd be useful.  This
hybrid would allow this, as information regarding the form of the routine
could be included in the structure.


Thanks,
Chris Campbell.


Julian Morrison <julian@extropy.demon.co.uk> wrote in message
news:980822461.5977.0.nnrp-12.9e98cc46@news.demon.co.uk...
> More interesting idea than "yet another VM", here's an idea (inspirations:
> the new Amiga's "Elate"OS, and Perl)
>
> Build what is not a VM, but actually a universal compiler backend. The
> input is not pseudo-machine-code, but a language independent  parse tree
> preserving full debugging semantics etc.
>
> The VM can compile it, interpret it, JIT it, whatever. It can also move
> slices of it to other machines or other processors transparently, or
> migrate it off an about-to-be swapped CPU onto another one without losing
> a beat. On each CPU it can optimize for the specific processor.
>
> Looks like a good idea to me, anyhow.