Re: Parrot for Ada?

[mike1@tumladen.net (Mike Greaves)]

Ingo Marks <adv@region-nord.de> wrote in message news:<ai9q8a$lan$04$1@news.t-online.com>...

> Parrot is an interesting virtual machine, similar to .NET CLR and JVM. It 

> Parrot was chosen to 
> implement Perl6 because .NET CLR and JVM would be "not suitable".

The reason that .NET and Java VM's are "not suitable" is that they both
spend CPU cycles to enforce types at runtime, if I understand it
correctly.  This "wasted performance" irked the Perl guys, who wanted
a non-type-aware VM for their almost-untyped "programming language"
(I use the term very loosely ;-)

More below...  I have a *bunch* of thoughts...


> AFAIK JGNAT is the only Ada compiler which compiles for a virtual machine 
> (JVM). I don't know if there will be well supported Ada compilers in the 
> future on upcoming platforms (64 bit AMD etc.) so I think it would possibly 
> be a good thing to have one working Parrot Ada compiler which could be used 
> on many platforms in the future.
> 
> Are there any Ada compiler experts here who could evaluate Parrot and tell 
> us if it could be(come) a suitable VM for Ada?

I am certainly NOT a "Ada compiler expert".  8-)
I am an experienced programmer (other languages), but an Ada *novice*.
I am not even positive how Ada code, running in a JVM via JGNAT, is
type checked; I assume that there is both compile- and run-time checking
there.

I DID spend a chunk of time reading about the Parrot VM a couple of
months back, mainly to see if it was suitable as a back-end for Python,
which is a good language for some problem domains.

Speaking from memory, and brief familiarity:  Parrot is a VM based on
both stacks *and* registers.  JVM is stack-based-only.  Parrot is built
around a kind of "virtual processor", and it's byte code bears some
resemblance to the instruction sets of the Motorola 68000, and other
*real* processors.  It's more like a hypothetical-conventional-processor
emulator than a usual virtual machine.  It is not clear to me personally,
whether this is genius or madness; and is left as an excercise for the
reader.  ;-)

Any type checking is done by the front-end compiler, the VM knows nothing
about types - just like a real processor, and unlike JVM.  Apart from
portability, Parrot gives you nothing more at run-time than native object
code does.

Since you need to test any serious program on any target where it may  
be run, it seems to me that to use Parrot as the back end for a
"traditional" compiled language is a little pointless.  It's kind of
like *deliberately* compiling your program for the *wrong* architecture,
and then running it in an emulator.  8-/

JVM has (arguably) value beyond it's portable byte-code, but Parrot
doesn't appear to.  And the reality of Java is *not* the promised "write
once, run anywhere", but "write once, *test everywhere*".  Maybe Parrot
will do better in the "run anywhere" department.

It's worth noting that Parrot is a 32-bit VM, and AMD's x86-64
architecture will run x86-32 object code efficiently.  So a program
compiled to Parrot bytecode, then run on x86-64/Hammer/Opteron will be
32-bit object code running *inefficiently* on a 64-bit processor.  While
a program compiled to x86-32 object code (with an *existing* gnat/x86
compiler), then run on x86-64/Hammer/Opteron will be 32-bit object code
running *efficiently* on a 64-bit processor.  Take your pick.  ;-)

I've run out of wind, at last...