Ada and JVM? Why not AdaVM?

Ada and JVM? Why not AdaVM?

[chris.danx]

Hi,
    I'm curious to know why everyones so keen to stick Ada 95 on the JVM.
Would a VM designed specifically for Ada 95 be of any benefit?  Or would it
be a pointless exercise (considering the development of JGNAT)?

((I'm not just talking about the VM here, but also about the APIs' provided
with it; As you know the Java APIs' are extensive))


I suppose I want to know the answer to the following.

    Does Ada have a VM which serves a similar purpose to the JVM for Java
(and is used in the same area)?

    If not, why not?

    And would there be any benefits in the design of such a system?


Maybe these are stupid questions, but sometimes they're the best kind of
questions to ask.


Thanks,
Chris Campbell

Re: Ada and JVM? Why not AdaVM?

[David Starner]

On Sat, 27 Jan 2001 16:47:45 -0000, chris.danx <chris.danx@ntlworld.com> wrote:
>Hi,
>    I'm curious to know why everyones so keen to stick Ada 95 on the JVM.
>Would a VM designed specifically for Ada 95 be of any benefit?  Or would it
>be a pointless exercise (considering the development of JGNAT)?

The advantages of the JVM are:

* Big name - everyone's heard of Java.
* There are a number of platforms that run JVM's that don't have an Ada 
  compiler ported to them.
* Allows you to run stuff in a web browser.
* Runs on the Java chip.
* Access to a huge API.

In comparasion, an AVM:

* No one has heard of it, and people would complain a lot less around
  here if everyone had heard of Ada in a positive light.
* AVM doesn't run on anything yet; written in C, you'll find it nearly
  as easy to port GNAT to anything gcc supports as port your AVM 
  (threading difficulties and the like); written in Ada makes it run on
  a subset of the platforms that Ada runs on. Java seems to be the only
  language that runs a significant number of platforms that Ada doesn't
  that supports threading, and besides performance problems, it's just 
  a little ironic . . . (Maybe Forth, but I'm not sure Forth's threading
  model would provide good support of Ada. You could portably emulate 
  threading in C or something, but that wouldn't be pretty.)
* You could make an AVM web plugin. Making a little bit more miserable for
  those of us who browse the web, and insuring that a large number of
  people (those who don't have compiled AVM plugins for their platform
  and those who don't care to download one) don't see it.
* The Ada chip is dead, and you'd lose a lot of flexibility designing 
  around it. ("Ada chip" = "the CPU of the computers Rational designed
  for running Ada". My knowledge of this is limited, so feel free to 
  correct me.)
* The API would be in direct proporition to the number of man-hours found
  to create and upkeep it. The Java API has had a lot of work put into
  it that will be hard to duplicate - the Classpath project has several
  years of work put into it, and they still have significant parts of the
  Java API unimplemented. Can you get even the level of support they have?

>I suppose I want to know the answer to the following.
>
>    Does Ada have a VM which serves a similar purpose to the JVM for Java
>(and is used in the same area)?

The JVM?

>    If not, why not?

No point? No need?

>    And would there be any benefits in the design of such a system?

Yes. You could make its quirks fit the quirks of Ada instead of those of
Java. It still doesn't outway the negatives.

-- 
David Starner - dstarner98@aasaa.ofe.org
Recovering from a hard drive "crash" - website down

Re: Ada and JVM? Why not AdaVM?

[Florian Weimer]

dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) writes:

> * AVM doesn't run on anything yet; 

You could target one of the existing VMs.  For example, you could
create a GNAT backend for the Guile, Python, or Emacs virtual machine.
Some day, if I have plenty of time, I plan to retarget JGNAT to one of
these platforms.  It's certainly a lot of useless fun. ;-)

Re: Ada and JVM? Why not AdaVM?

[Ronald Cole]

Florian Weimer <fw@deneb.enyo.de> writes:
> You could target one of the existing VMs.  For example, you could
> create a GNAT backend for the Guile, Python, or Emacs virtual machine.
> Some day, if I have plenty of time, I plan to retarget JGNAT to one of
> these platforms.  It's certainly a lot of useless fun. ;-)

Don't forget about the Western Digital Pascal Microengine...

-- 
Forte International, P.O. Box 1412, Ridgecrest, CA  93556-1412
Ronald Cole <ronald@forte-intl.com>      Phone: (760) 499-9142
President, CEO                             Fax: (760) 499-9152
My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084  4A88 8851 E6C8 69E3 B00B

Re: Ada and JVM? Why not AdaVM?

[Brian Rogoff]

On 29 Jan 2001, Ronald Cole wrote:
> Florian Weimer <fw@deneb.enyo.de> writes:
> > You could target one of the existing VMs.  For example, you could
> > create a GNAT backend for the Guile, Python, or Emacs virtual machine.
> > Some day, if I have plenty of time, I plan to retarget JGNAT to one of
> > these platforms.  It's certainly a lot of useless fun. ;-)
> 
> Don't forget about the Western Digital Pascal Microengine...

I think the obvious targets are the CLR from Microsoft, and the Inferno VM
(Dis?) from Lucent. Oh, it's a joke thread. Well then the Ocaml byte code 
of course ;-)

-- Brian

Re: Ada and JVM? Why not AdaVM?

[Florian Weimer]

Ronald Cole <ronald@forte-intl.com> writes:

> Florian Weimer <fw@deneb.enyo.de> writes:
> > You could target one of the existing VMs.  For example, you could
> > create a GNAT backend for the Guile, Python, or Emacs virtual machine.
> > Some day, if I have plenty of time, I plan to retarget JGNAT to one of
> > these platforms.  It's certainly a lot of useless fun. ;-)
> 
> Don't forget about the Western Digital Pascal Microengine...

The Python and Emacs VMs are quite widespread and platform independent
(the Emacs VM has probably been ported to more platforms than the
JVM).  And both support loading arbitrary bytecode (AFAIK, Perl does
not), so it's really possible to adapt an Ada compiler to this
platform.

(BTW: Will Microsoft make the .NET VM specification public?  And if
they do, will they encourage third-party implementations?)

Re: Ada and JVM? Why not AdaVM? ms .net vm

[Singlespeeder]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87ae89e95w.fsf@deneb.enyo.de...
> (BTW: Will Microsoft make the .NET VM specification public?  And if
> they do, will they encourage third-party implementations?)

So that we can play 'spot the difference' with the JVM specification :-)

Nick

Re: Ada and JVM? Why not AdaVM?

[Ronald Cole]

Florian Weimer <fw@deneb.enyo.de> writes:
> The Python and Emacs VMs are quite widespread and platform independent
> (the Emacs VM has probably been ported to more platforms than the
> JVM).  And both support loading arbitrary bytecode (AFAIK, Perl does
> not), so it's really possible to adapt an Ada compiler to this
> platform.

Last time I checked, the emacs "vm" was a lisp interpreter.  Why would
anyone want an Ada to emacs-lisp translator?

-- 
Forte International, P.O. Box 1412, Ridgecrest, CA  93556-1412
Ronald Cole <ronald@forte-intl.com>      Phone: (760) 499-9142
President, CEO                             Fax: (760) 499-9152
My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084  4A88 8851 E6C8 69E3 B00B

Re: Ada and JVM? Why not AdaVM?

[Florian Weimer]

Ronald Cole <ronald@forte-intl.com> writes:

> Florian Weimer <fw@deneb.enyo.de> writes:
> > The Python and Emacs VMs are quite widespread and platform independent
> > (the Emacs VM has probably been ported to more platforms than the
> > JVM).  And both support loading arbitrary bytecode (AFAIK, Perl does
> > not), so it's really possible to adapt an Ada compiler to this
> > platform.
> 
> Last time I checked, the emacs "vm" was a lisp interpreter.

Emacs has both, a Lisp interpreter and a VM (or "bytecode
interpreter").  Obviously, you would target the bytecode and not the
Lisp interpreter.

> Why would anyone want an Ada to emacs-lisp translator?

Why would anyone want an Ada to Java translator? ;-)

Re: Ada and JVM? Why not AdaVM?

[Ray Blaak]

Florian Weimer <fw@deneb.enyo.de> writes:
> Ronald Cole <ronald@forte-intl.com> writes:
> > Why would anyone want an Ada to emacs-lisp translator?
> 
> Why would anyone want an Ada to Java translator? ;-)

See my other reply in this thread. The JVM can support real languages. Emacs
bytecode interpreter supports only Elisp -- completely dynamic, no lexical
scoping, etc.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Ada and JVM? Why not AdaVM?

[Tarjei T. Jensen]

Ronald Cole wrote in message ...
>Florian Weimer <fw@deneb.enyo.de> writes:
>> The Python and Emacs VMs are quite widespread and platform independent
>> (the Emacs VM has probably been ported to more platforms than the
>> JVM).  And both support loading arbitrary bytecode (AFAIK, Perl does
>> not), so it's really possible to adapt an Ada compiler to this
>> platform.
>
>Last time I checked, the emacs "vm" was a lisp interpreter.  Why would
>anyone want an Ada to emacs-lisp translator?

To write Emacs code in Ada of course.


Greetings,

Re: Ada and JVM? Why not AdaVM?

[Ray Blaak]

"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:
> Ronald Cole wrote in message ...
> >Last time I checked, the emacs "vm" was a lisp interpreter.  Why would
> >anyone want an Ada to emacs-lisp translator?
> 
> To write Emacs code in Ada of course.

A noble sentiment, but largely impractical.

To do anything real in Emacs one tends to need a substantial understanding of
Elisp anyway. Having Ada as an intermediate layer is just artificial work.

The main benefit Ada provides is to provide strong static type checking. Elisp
has essentially zero static typing. It is completely dynamic with no lexical
scoping.

E.g.

  (defvar greetings "Hi there")

  (defun show-message () (message greetings))

  (defun show-message-from-inside ()
    (let ((greetings "Hi from inside"))
      (show-message)))

Executing show-message-from-inside causes the string "Hi from inside" to be
displayed in Emac's message line. A lexically scoped language would display
"Hi there".

Interfacing to a library implemented in Elisp would be a challenge, to say the
least.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Ada and JVM? Why not AdaVM?

[joswig]

In article <m3zog7i84b.fsf@yakisoba.forte-intl.com>,
  Ronald Cole <ronald@forte-intl.com> wrote:
> Florian Weimer <fw@deneb.enyo.de> writes:
> > The Python and Emacs VMs are quite widespread and platform independent
> > (the Emacs VM has probably been ported to more platforms than the
> > JVM).  And both support loading arbitrary bytecode (AFAIK, Perl does
> > not), so it's really possible to adapt an Ada compiler to this
> > platform.
>
> Last time I checked, the emacs "vm" was a lisp interpreter.

Look again. Emacs has a VM *and* a lisp interpreter.


Sent via Deja.com
http://www.deja.com/

Re: Ada and JVM? Why not AdaVM?

[Nick Roberts]

"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:94vdt9$a2g1@news.cis.okstate.edu...
> ...
> * The Ada chip is dead, and you'd lose a lot of flexibility designing
>   around it. ("Ada chip" = "the CPU of the computers Rational designed
>   for running Ada". My knowledge of this is limited, so feel free to
>   correct me.)

I believe the original 'Ada chip' (as such) was the Intel 432, many moons
ago (a 16-bit single backplane multiprocessor architecture). Sadly, it was
cancelled due to lack of intere$t*.

(Anyway, you don't need an Ada-specific CPU, you only need an Ada-specific
OS ;-)

--
Nick Roberts
http://www.AdaOS.org


*Actually, due to Intel deciding to concentrate all its powers on the then
new and astonishing iAPX 386.

Re: Ada and JVM? Why not AdaVM?

[Larry J. Elmore]

Nick Roberts wrote:

> "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
> news:94vdt9$a2g1@news.cis.okstate.edu...
> > ...
> > * The Ada chip is dead, and you'd lose a lot of flexibility designing
> >   around it. ("Ada chip" = "the CPU of the computers Rational designed
> >   for running Ada". My knowledge of this is limited, so feel free to
> >   correct me.)
>
> I believe the original 'Ada chip' (as such) was the Intel 432, many moons
> ago (a 16-bit single backplane multiprocessor architecture). Sadly, it was
> cancelled due to lack of intere$t*.
>
> (Anyway, you don't need an Ada-specific CPU, you only need an Ada-specific
> OS ;-)

> *Actually, due to Intel deciding to concentrate all its powers on the then
> new and astonishing iAPX 386.

The lack of interest in the iAPX-432 was caused by the 432's severe lack of
performance. Unfortunately, it's failure was also perceived by many to also
be the failure of the ideas behind the architecture. The 432 might not have
been a stellar performer even with the best possible implementation of the
architecture, but a lot of truly terrible decisions were made in its actual
implementation that effectively crippled it.

The move to the i386 was a result of the 432's failure and the enormous
profits generated by the 8086/88 line.

It seems to me that the Itanic may end up following the 432. If the IA-64
architecture doesn't go down the tubes, I think it will be due to HP's
implementation. If the architecture is judged to be a failure, it would be
ironic if Intel had to follow AMD's lead in the 64-bit x86 architecture.

Larry

Re: Ada and JVM? Why not AdaVM?

[Robert Dewar]

In article <3A79FE73.3D7F12A0@home.com>,
  "Larry J. Elmore" <ljelmore@home.com> wrote:
> Nick Roberts wrote:

> > I believe the original 'Ada chip' (as such) was the Intel
> > 432, many moons
> > ago (a 16-bit single backplane multiprocessor
> > architecture). Sadly, it was
> > cancelled due to lack of intere$t*.
> >
> > (Anyway, you don't need an Ada-specific CPU, you only need
> > an Ada-specific OS ;-)

The i432 was a very odd design, which was certainly not done
with Ada in mind (not clear *what* was in mind, this chip was
doomed to fail, since it was impossible to implement
efficiently). The attempt to make it into an Ada chip was
one of the last gasp attempts to bail this chip out of
catastrophe -- it failed, Ada projects were not about to
buy an unsuitable inefficient chip just because it had an
Ada label on it.

> > *Actually, due to Intel deciding to concentrate all its
> > powers on the then new and astonishing iAPX 386.

I don't think that claim has any historical basis, the i432
failed on its own merits.

> The lack of interest in the iAPX-432 was caused by the 432's
> severe lack of performance.

Indeed

> Unfortunately, it's failure was also perceived by many to
> also be the failure of the ideas behind the architecture.

Entirely fair, the design was misconceived

> The 432 might not have been a stellar performer even with the
> best possible implementation of the
> architecture

Indeed.

> but a lot of truly terrible decisions were made in its actual
> implementation that effectively crippled it.

Nothing could have rescued it in my opinion. The design had the
appearence of being done by high level language folks with no
view of what could be implemented efficiently. There was really
nothing specifically Ada about the design.




Sent via Deja.com
http://www.deja.com/

Re: Ada and JVM? Why not AdaVM?

[Larry J. Elmore]

Robert Dewar wrote:

> In article <3A79FE73.3D7F12A0@home.com>,
>   "Larry J. Elmore" <ljelmore@home.com> wrote:
>
> > Unfortunately, it's failure was also perceived by many to
> > also be the failure of the ideas behind the architecture.
>
> Entirely fair, the design was misconceived

It's been a _long_ time since I've read anything detailed on the 432,
but it seemed to me that some of its ideas had merit -- at least if your
goal was safety and reliability, not speed. Whether that might be better
done by software I honestly don't know.

> > The 432 might not have been a stellar performer even with the best
> possible implementation of the

> > architecture
>
> Indeed.

Yes, I should have said _could not_, not "might not".

>
> > but a lot of truly terrible decisions were made in its actual
> > implementation that effectively crippled it.
>
> Nothing could have rescued it in my opinion. The design had the
> appearence of being done by high level language folks with no
> view of what could be implemented efficiently.

Then those who implemented the hardware made things even worse.

> There was really
> nothing specifically Ada about the design.

Custom microcode could be provided, though. I remember reading an
article about a 432 with microcode specifically written to support
Smalltalk's VM. I don't specifically recall what the performance was,
but the combination of the 432 and Smalltalk must've been truly
glacial...

Larry

Re: Ada and JVM? Why not AdaVM?

[Tucker Taft]

Robert Dewar wrote:
> 
> In article <3A79FE73.3D7F12A0@home.com>,
>   "Larry J. Elmore" <ljelmore@home.com> wrote:
> > Nick Roberts wrote:
> 
> > > I believe the original 'Ada chip' (as such) was the Intel
> > > 432, many moons
> > > ago (a 16-bit single backplane multiprocessor
> > > architecture). Sadly, it was
> > > cancelled due to lack of intere$t*.
> > >
> > > (Anyway, you don't need an Ada-specific CPU, you only need
> > > an Ada-specific OS ;-)
> 
> The i432 was a very odd design, which was certainly not done
> with Ada in mind (not clear *what* was in mind, this chip was
> doomed to fail, since it was impossible to implement
> efficiently). ...
> Nothing could have rescued it in my opinion. The design had the
> appearence of being done by high level language folks with no
> view of what could be implemented efficiently. There was really
> nothing specifically Ada about the design.

I thought the 432 was an attempt to implement many of the
ideas of the capability-based Hydra operating system in hardware.

Capability-based operating systems were pretty hot for a while,
but someone forgot that 90% of the usefulness of an operating system 
(as opposed to a real-time executive) is at the shell/tool level, and
Hydra never got there.  Mach, which was a follow-on to the
Hydra work, included a Unix emulator on top of it, and that is
probably what has kept it alive so long, and now appearing in a local
MacOS-X near you... 

-- 
-Tucker Taft   stt@avercom.net   http://www.averstar.com/~stt/
Chief Technology Officer, AverCom, Inc. (A Titan Company) Burlington, MA  USA
(AverCom was formed 1/1/01 from the Commercial Division of AverStar)
(http://www.averstar.com/services/ebusiness_applications.html)

Re: Ada and JVM? Why not AdaVM?

[Ted Dennison]

In article <3A7F032B.380BD35D@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Hydra never got there.  Mach, which was a follow-on to the
> Hydra work, included a Unix emulator on top of it, and that is
> probably what has kept it alive so long, and now appearing in a local
> MacOS-X near you...

Not to mention GNU Hurd.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Ada and JVM? Why not AdaVM?

[Pat Rogers]

"Tucker Taft" <stt@averstar.com> wrote in message
news:3A7F032B.380BD35D@averstar.com...
> Robert Dewar wrote:
<snip>
> > The i432 was a very odd design, which was certainly not done
> > with Ada in mind (not clear *what* was in mind, this chip was
> > doomed to fail, since it was impossible to implement
> > efficiently). ...
> > Nothing could have rescued it in my opinion. The design had the
> > appearence of being done by high level language folks with no
> > view of what could be implemented efficiently. There was really
> > nothing specifically Ada about the design.
>
> I thought the 432 was an attempt to implement many of the
> ideas of the capability-based Hydra operating system in hardware.

That's what Elliott Organick's book* indicates (pg. 12).

We had the pleasure of experimenting/exploring/playing with one of them,
back in the very early 1980's.  An interesting machine with some unusual Ada
extensions, but I would not have wanted to do serious development with it.

* E. Organick, A Programmer's View of the Intel 432 System, Aloha, Oregon:
Intel Corporation, 1983.

Re: Ada and JVM? Why not AdaVM?

[gdemont]

Maybe it would be a VM & API too much ? IMHO Ada's strength
is to have a wide portability while being able to compile
to optimised native code. A bit of chameleon-ism. You want
also a portable compiled code ? JVM is there. You want
efficient numerics (e.g.) ? You recompile for the target
processor & OS. I just recompiled a big simulation program
developed on a Compaq server (Alpha/OpenVMS/DEC Ada) on my
laptop (PC/Win98/GNAT). Just 1 mistake DEC Ada did not see
and 1 Ada83 -> Ada95 incompatibility to correct, and it runs.
That flexibility is the big advantage for me. A dedicated VM
would - maybe - be contra-productive in that sense. Again, IMHO...
__________________________________________
Gautier  --  http://www.diax.ch/users/gdm/


Sent via Deja.com
http://www.deja.com/

Re: Ada and JVM? Why not AdaVM?

[Julian Morrison]

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.

Re: Ada and JVM? Why not AdaVM?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]


"Julian Morrison" <julian@extropy.demon.co.uk> a �crit dans le 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.

Sure. You could even call it ANDF. And there's already an Ada compiler for it (DDC).

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Ada and JVM? Why not AdaVM?

[John English]

Julian Morrison wrote:
> 
> 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.

Yup, just like UNCOL looked like a good idea in about 1960... ;-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Ada and JVM? Why not AdaVM?

[chris.danx]

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.